Access violation on exit


#1

I’m having difficulty in debugging a problem I get when my app closes. If I close whilst running the debugger I get an access violation and the debugger brings me to the following code in juce_Win32_Windowing.cpp:

static void* callFunctionIfNotLocked (MessageCallbackFunction* callback, void* userData)
{
    if (MessageManager::getInstance()->currentThreadHasLockedMessageManager())
        return callback (userData);
    else
        return MessageManager::getInstance()->callFunctionOnMessageThread (callback, userData);
}

It is the ‘return callback(userData)’ that seems to be causing the problem but only on exit. If I add breakpoints to the function and step through I don’t get any problems therefore I’m finding it hard to debug the problem. Can any of you suggest a way for me to go about finding a solution to this issue? I’m kind of at a loss. For what it’s worth my app exits without any problems on Linux. Thanks.


#2

If I faced that problem, I would first think that maybe there are some timing issues (i.e., stepping through code is much slower than executing at run-time). I would place long delay timers between each line of code in question to (hopefully) find the bug or, if no dice, at least rule out timing as the potential sticking point.


#3

callFunctionIfNotLocked just invokes other functions - you’d need to look at the stack to see exactly what is calling it, and what they’re trying to do.


#4

Would I be right in assuming it’s a call to GetDC() that’s causing the problem(see attached screenshot). If so how can I go about debugging things in a pre-compiled dll? Please be patient with me, I’ve now gone further than I’ve ever gone before into the depths of computer science…I know that’ll make some of you guys laugh but there you go. Longest of journeys one step sort of thing…


#5

Make sure you delete all your UI components in JUCEApplication::shutdown, and don’t leave any hanging around until your application’s destructor is called. All the event-handling code may already have been unloaded by the time it gets there.


#6

In my JUCEApplication::shutdown() method I zero my documentWindow derived class, ala HostStartup.cpp from the plugin host demo. (my app is a standalone filter type thing). To keep in line with the JUCE manifesto I’ve made sure that my standalone filter window, plugin processor, and plugin editor classes only use scoped pointers and owned arrays. Am I right in saying that owned arrays are lists of scoped pointers so they don’t have to be deleted explicitly? Or do I have to at least call clear() in my destructors? By following this line of programming am I not making sure that everything is deleted gracefully, therefore there shouldn’t be anything left when my applications destructor is called? All my classes use the JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR macro and there are no leaks being reported. Am I right in assuming it’s most likely a memory leak which is the cause of the problem? If so I’ll keep checking to see if I missed something. Thanks.


#7

Figuring out why a program is functioning incorrectly is very often more difficult than writing it in the first place, especially when building concurrent systems.


#8

Well, according to the stack trace above it’s being deleted in your destructor, so you should probably do some proper debugging there and see what’s really happening.


#9

Thanks for the pointers, no pun intended. The more I dig the closer I’m getting to the finding the problem. I’m confident I’ll find a solution shortly.

Rory.