Stack Overflow in Propeller Tool 2.5.3.0
jay_harlow
Posts: 43
in Propeller 2
When I click the Propeller Tool icon I'm getting a _Stack Overflow Exception. I've uninstalled and reinstalled to no avail.
It was working fine, I made a plathora of changes
Attached is a copy of Propeller log
Any thoughts?
Jay
Comments
This happens at startup? I've sometimes seen funny things when closing Prop Tool, not sure I've seen this on opening...
I guess I would try to remove all parallax things from the registry using regedit and then try reinstalling.
I see some stuff here: Computer\HKEY_CURRENT_USER\SOFTWARE\ParallaxInc\Propeller\2.4.0
[Please read fully before you do anything]
Thanks for the log file. Looking at it, it appears to have failed while retrieving syntax highlighting attributes, probably in the midst of rendering the editor view. I definitely haven't seen that happen before, so I haven't been looking in that area of code to find this problem.
Do you remember, by chance, if you had made any changes to your syntax highlighting preferences before the problem occurred?
Deleting the 2.4.0 folder from the Computer\HKEY_CURRENT_USER\SOFTWARE\ParallaxInc\Propeller\ that @Rayman reported is the exact step I recommend as well. The uninstaller doesn't remove those settings because they are shared among minor versions/patches.
If you have Propeller Tool installed still, that's okay. Simply close Propeller Tool (if it's running), delete the 2.4.0 folder from that hive path, then run Propeller Tool again. Propeller Tool will recreate all those settings from defaults internally while running, and will save them again to the registry upon the next moment it is closed.
There seems to be a few customers experiencing strange things upon starting Propeller Tool. Maybe this is one of them? The version hasn't changed in a while, so I can only imagine that it has to do with a bug that wasn't exposed until a certain Windows 10 update was applied to the system recently. Weeks? Month? This is likely (and I'm just guessing) an order-of-event change that is now happening more frequently in Windows but I have yet to find it.
If you wouldn't mind, before deleting that hive folder, please save it to send to me us at developer@parallax.com, so I have a better chance of duplicating the issue (which isn't happening to me) on our side and nab this issue.
@"Jeff Martin" I frequently get funky behavior that I think is caused by rendering the background colors and syntax highlighting; a large section appears selected, except that it has a white background. Toggling between Summary and Full Source tends to correct the problem. This isn't a new problem -- it goes back a long time, hence probably code you've not looked at for a while.
@JonnyMac I'd like to see a sample of that. Can you screenshot (or video capture it happening, ideally) and post to https://github.com/parallaxinc/propeller-tool/issues when it's convenient?
I will the next time that happens -- which is usually a few times each day.
Jeff deleting the Hive folder fixed the problem.
I sent you an email with the reg file
Jay
Got it! Thank you. I tried it out on my system and BAM! Stack Overflow!
I've never been so happy to get a stack overflow!
I can't get to the error details though. In my case, the splash screen is in the way and the dialog won't move for me. Selecting from task bar doesn't help; it's only momentary and I can't get the mouse to the link. Going to try stepping through the code on my dev box.
What worked for me was starting Propeller Tool from a secondary monitor., where Propeller Tool is pinned to the task bar, The splash window should show on monitor #1, the error window on monitor #2,
Jay
Great you got it fixed! That's Windows for you.
I'm still tracking down the source of the problem.
Through good 'ol binary search and destroy technique, I narrowed it down to just one registry setting. With it, stack overflow on startup; without it, no problem.
So what is it? It doesn't make sense... it's the value of the 2nd replacement (as in find and replace) history, where @jay_harlow happened to search for a method name with ending parenthesis. I can't think of anything that should cause that startup routines to fail in this way because of a replacement field value.
On the way to finding it, I discovered that it only happens when run full speed on my test machine, but not while debugging on my dev machine. So I've had to sprinkle in logging messages to track and narrow down where the code blows up. To my surprise (but I shouldn't have been surprised), it doesn't blow up in the code that directly adds that replacement history into the find/replace control upon the session start; instead, it's dying somewhere earlier. The hunt is still on. I'm getting back to it this morning.
Easy solution: get rid of find history :P
Really though, the autocomplete in the find/replace box is extremely obnoxious, it just overwrites what's in there when you try to do a minor edit.
Without seeing the code it is hard to tell, but any chance the search and repeat runs in an infinite recursive loop ? Like the replacement is also a match for the string to be replaced causing an infinite loop ?
When a bug shows when running normal but not when debugging, 99% of the times it is a wild pointer. Debuggers usually initializes memory to 0, any uninitialized pointer may work well when debugging because of null checks but fails randomly with normal runs.
Hope this helps.
I just made my Prop Tool crash the same way by copy and replacing large amounts of text (two times), closing and then restarting.
Maybe this is running in a thread that doesn't have enough memory? Or maybe string buffer being read to isn't big enough?
Or, maybe the writing to registry needs to limit the string size or something...
Also, for me, the error window is hidden behind the splash screen and I can't seem to actually get to to click on it.
I can close the error window from the toolbar though and when I do the Prop Tool launches looking normal. Crashes on exit though...
Fixed it by deleting those two find and also replace registry entries.
Thanks @macca and @Rayman.
The problem seems to occur when the initialization routines parse the style rules and apply them to the style engine. I remember having to do some work in this area to make it support the two different styles (P1 vs P2) and likely caused this problem, but don't know why it didn't show up until now. It doesn't appear to have anything directly to do with the replacement value I noted before, other than the replacement value must be specific to cause the failure... all this together is pointing to a likely cause being a pointer issue (like suggested) or an errant range perhaps that overruns an array but only causes strange errors to occur rather than an index out-of-bounds error.
I am suspecting a recursive routine that seems to be at play, but I haven't yet modified it to prevent recursion (as a test) because of the following I'm exploring...
Just noted that when updating the styles, if I throw a log message right before each individual style is "applied" to the style engine, the problem disappears. That really speaks of a difficult to find issue, like a pointer issue... something that's a problem when things are running fast but magically isn't a problem when the same code is running slower (ie: perhaps a memory management issue). The fact that it shows as a stack overflow indicates I have faulty logic somewhere, like the recursive routine (which I'll review and modify for experiment) but is a transient problem that is cleared up by the code running slower and the OS cleaning something up in memory before the errant code sees it.
Thanks @Rayman - I'll have to consider and check on that. I'm not aware of a limit like that in the registry; at least one that we'd practically reach.
I tried this find/replace large text out on Prop Tool 1.3 and it still works...
Maybe it is something new then...
That's my theory also.
Once I find it, I'm hoping you may try your hand at stack overflowing it again with your large copy/replace.
Jeff, you may want to try running Valgrind/LeakCheck against it.
That's likely to be a buffer overflow. The log message call alters the stack content in a way that it is no longer a problem, or maybe just mitigates the problem making it more random. This could also be an indication that it is not really a recursion issue rather a stack corruption that causes a return to the wrong location resulting in a unwanted recursive loop. Difficult to debug, review the local variables involved and maybe increase th size of strings/buffers. Tools like valgrind, as suggested by Circuitsoft may as well help a lot in these cases.
Almost forgot. This thread https://forums.parallax.com/discussion/comment/1523992/#Comment_1523992 reports a similar issue and suggest a relationship with the last recently used files registry entries. I don't know when the lru files are read, but could be the issue really a side-effect of another issue ? If the lru are readed in an undersized buffer it could explain something.
There is also the binary include instruction that causes issues because the editor attempts to read the file in memory and chokes https://forums.parallax.com/discussion/comment/1522677/#Comment_1522677