My Juce-based application crashes when I exit, but what makes it hard to debug is that the debug version doesn’t do this. Furthermore, even the Release version doesn’t crash when launched from Visual. It’s only the release version when launched by itself. Not easy to track it down from the sources revisions either, as this problem seems to been more or less gone then back and so on since some time. When there, the probem makes the app crash systematically on my machine (Win7 64bit), but it seems to work fine on at least some other machines (likely with older OS, but not sure there’s any correlation…)
Any idea where to look for the bug? I know debug versions allocate extra space around variables, etc, which can avoid overwriting one with the adjacent one in debug and make the problem only occur in release mode, but I get no warning at all in debug, and once again there’s this weird thing that the release version doesn’t crash at exit when it was launched from Visual…
After having (unsuccessfully) tried to disable big chunks of the app in order to localize the problem (finally not really feasible, due to complex interactions between main objects…), I reverted back to what I think is the same code as before, and the latest compile doesn’t crash anymore. I had tried to clear the release folder and rebuild all earlier with no luck though, so it didn’t look like a corrupted build situation… So, the problem is gone, but will likely be back again anytime soon, and still don’t know what’s going on. Now I wonder if it has anything to do with Juce, or even with my code…
Did anyone experience such thing?
When the app is launched with a debugger attached, even if it is the Release target of the application, there are hooks placed into the running application for various events. For example, when an exception is thrown. These hooks will make the timing behavior of a multi-threaded app different when launched with an attached debugger, versus launched regularly.
I suggest you analyze the flow of control of whatever threads you have running, when the exit signal is received.
I experience the same error when leaving the application, but both in release and in debug mode (in VS Express 2010). It disappears as soon as I only have a single DocumentWindow without any children, and reappears as soon as the DocumentWindow creates any children (Component). Rebuild doesn’t help either.
It seems to be related to the =operator of the ScopedPointer.
I am rather new to JUCE so this might also stem from some basic misuse of the JUCE-library, but I can’t find the cause.
Any ideas what this could be?
Well, the first thing to check is what kind of exception? Best guess is that it is a memory access error. The most common cause for a crash on exist for a C++ program is an attempt to access an object that has already been freed.
Let’s take the case of a ScopedPointer. Put simply, it is a maid service. Go ahead and allocate, I’ll clean up… When you assign somethign new to it, the previous contents are deleted. Likewise, when the ScopedPointer itself goes out of scope, it frees its contents (if any), hence the name.
Now, say your have a compontent pointer in a scoped pointer. If you try to access that component after the scoped pointer itself has gone out of scope, exploding is to be expected.
Another possibility is writing past the boundary of an allocation. In debug builds on Windows there is more memory padding between certain types of things, so overwrites can sometimes be non-catastrophic, until you switch to release mode.
There are some JUCE specific ways to crash on exit. For example, there is a member in your application class that let’s you decide wether or not to allow exit to proceed. If you throw up a modal alert at that point, you can get the underlying Run displatch loop all whacked out on Mac and crash when you let exit proceed. But, most the time catastrophy on exit is a memory managment issue. If you don’t have debugging available to you, you could try Logger::outputDebugString(). Basically follow the tear down of the system in messages and see where you are crashing. Often the incompatible seqeunce of events will stand right out. Even if that isn’t the case, you can keep adding messages to hone in on the exact offending line.
The comment in line 71 in juce_ResizableWindow.cpp gives the answer:
" Don’t delete or remove the resizer components yourself! They’re managed by the
// ResizableWindow, and you should leave them alone! You may have deleted them
// accidentally by careless use of deleteAllChildren()…? "
This was exactly what caused the error in my case.