Release build crash

General JUCE discussion
1

I’m making a little application that when in release build, it sometimes crashes in TypefaceCache destructor on application exit. Stack:

[size=75]ntdll.dll!7c910f29() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] ntdll.dll!7c910d5c() MyAppl.exe!_VEC_memzero(void * dst=0x00c30000, int val=0, int len=0) + 0x82 bytes C ntdll.dll!7c91056d() MyAppl.exe!free(void * pBlock=0x011ffa78) Line 110 C MyAppl.exe!juce::TypefaceCache::`vector deleting destructor'() + 0x15 bytes C++ MyAppl.exe!juce::DeletedAtShutdown::deleteAll() + 0xca bytes C++ MyAppl.exe!juce::shutdownJuce_GUI() + 0xe bytes C++ MyAppl.exe!juce::JUCEApplication::shutdownAppAndClearUp() + 0x5e bytes C++ MyAppl.exe!juce::JUCEApplication::main() + 0x251 bytes C++ MyAppl.exe!WinMain(int __formal=0, int __formal=0, const char * commandLine=0x00400000, int __formal=0) Line 242 + 0x69 bytes C++ MyAppl.exe!__fFCOSH() + 0xbe81 bytes C++ kernel32.dll!7c816fd7() gdi32.dll!77f170d6() [/size]

Odd thing is that if I use debug info in the exe to be able to debug it, this never happens, only when I run it out of the debugger (WinXP, VC++ 2005).

Any idea as to why this might be? Timing issue?

TIA
/R

2

That is pretty odd, and I’ve not seen the same thing before… Could it be that something else is corrupting some memory?

3

I have problems with mem leak reports in debug build which I haven’t been able to track down just yet. Might have something to do with it…

4

Alas… after finding the leak, the problem is still there. Now it crashed in a different place:

[size=75]
ntdll.dll!7c910f29()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!7c910d5c()
ntdll.dll!7c910e91()
ntdll.dll!7c91056d()
ntdll.dll!7c910551()
ntdll.dll!7c91056d()

MyAppl.exe!free(void * pBlock=0x011f10a8) Line 110 C
MyAppl.exe!juce::SortedSet<void *,juce::DummyCriticalSection>::minimiseStorageOverheads() Line 581 + 0x14 bytes C++
MyAppl.exe!juce::SortedSet<void *,juce::DummyCriticalSection>::remove(const int indexToRemove=0) Line 485 C++
MyAppl.exe!juce::ApplicationCommandManager::removeListener(juce::ApplicationCommandManagerListener * const listener=0x011e7f90) Line 315 + 0x18 bytes C++
MyAppl.exe!juce::MenuBarComponent::~MenuBarComponent() Line 78 C++
MyAppl.exe!juce::MenuBarComponent::scalar deleting destructor'() + 0x8 bytes C++ MyAppl.exe!juce::DocumentWindow::~DocumentWindow() Line 73 C++ MyAppl.exe!MyApplWindow::~MyApplWindow() Line 156 + 0xf bytes C++ MyAppl.exe!MyApplWindow::scalar deleting destructor’() + 0x9 bytes C++
MyAppl.exe!MyApplApplication::shutdown() Line 230 C++
MyAppl.exe!juce::JUCEApplication::shutdownAppAndClearUp(bool useMaximumForce=false) Line 271 C++
MyAppl.exe!juce::JUCEApplication::main(juce::String & commandLine={…}, juce::JUCEApplication * const app=0x00c54f68) Line 238 + 0x9 bytes C++
MyAppl.exe!WinMain(int __formal=4194304, int __formal=4194304, const char * commandLine=0x00601064, int __formal=4194304) Line 257 + 0x69 bytes C++
MyAppl.exe!__tmainCRTStartup() Line 315 + 0x1c bytes C
kernel32.dll!7c816fd7()
gdi32.dll!77f170d6()[/size]

This might ring a bell for someone… for me there is complete silence…

TIA
/R

5

Looks to me like your main window is a dangling pointer when it gets deleted…

6

The whole application is built out of juce_application demo project, and I know for sure that the main window is deleted at one location only (in the shutdown() method of the application). I’ll keep digging.

7

Interesting. My application was using the native title bar (Windows). But as soon as I tested without native title bar… no more crashes.

Switching back to native titlebar… crashes. :frowning:

Hope that triggers some ideas?

/R

8

My bad. An ApplicationCommandManager instance was living inside the main window instance (getting destroyed at the same time as the main window). By moving the instance into the application object, it seems to work fine now even with native title bar. Phew.

/R

9

Thought it would be something like that. If you can think of anywhere that I could put an assertion to catch things like that in the debug build, let me know.