LeakedObjectDetector hits before systemRequestedQuit is called



when I quit my application using Cmd+Q on Mac OS X, the LeakedObjectDetector hits from within MessageManager::runDispatchLoop. The method systemRequestedQuit of my application is never called which would clean up the remaining objects.

I was wondering if it is correct that using Cmd+Q does not trigger systemRequestedQuit().




Tried this myself and cmd-Q certainly does call systemRequestedQuit()

But, you shouldn't be doing any clean up in there! Your cleanup should only go in the shutdown() method.

For me the leak detection hits before shutdown() or systemRequestedQuit() are called.

When I remove the leak detection assertfalse just to see if shutdown and systemRequestedQuit are called at all and they are not.


Are those called after the window has been destroyed?

I wonder when the application closed through Cmd+Q where the currently open windows should be destroyed.


I will cross-check with Windows just in case. Maybe the application instance is cleared for some reason.

Hey Jules,


I cross checked my issue with the JUCE Demo. It is as you said, but sadly that does not change my issue.

In my application not even JUCEApplicationBase::appWillTerminateByForce() is called, even when I put a hard crash into it, it does not trigger so it can also not be a debugger issue.

I use custom code to create my application object but of course stick to the JUCEApplication class for it.


Do you have a suggestion why the event handler does not seem to be in place?

Also when I register application commands with shortcuts they do not work, maybe that is related.

I attached my callstack and the one from the demo, maybe that gives someone an idea what could be wrong.





Okay I think I get an idea what is wrong.


There are certain function calls that rely on the application object to exist which triggers the MessageManager to be initialised.

I found ScopedJuceInitialiser_GUI and LookAndFeel::setDefaultLookAndFeel.

I wonder what the correct order is for those. It seems like the application object should be the first one to be created.

Also as I create my application instance myself, I overloaded JUCEApplicationBase::isStandaloneApp() to always return true.

Does this have other implications beyond what I see right now?



Ah, if you're going off-piste and doing the startup process yourself, then all bets are off. But yes, as long as you use those initialiser functions, that should be most of what you need.

I modified my code so it sticks to the original initialisation code but that did not help.

AppDelegate is correctly created and the following lines are correctly executed:

[NSApp setDelegate: delegate];

[[NSDistributedNotificationCenter defaultCenter]
     addObserver: delegate
        selector: @selector (broadcastMessageCallback:)
            name: getBroadcastEventName()
          object: nil];

Still none of the oberservers is called, not even applicationWillFinishLaunching.

Could it be that there is an problem with the return value of getBroadcastEventName?

The broadcaster stuff is unrelated, it's just for interprocess messages.

The mainmenu tracking works. So it is only the observers for NSDistributedNotificationCenter that do not work.

Is there a deeper meaning behind getBroadcastEventName()? Because broadcastMessageCallback is never called.

It's irrelevant to what you're trying to do.

Okay thanks for the info.


I do not know if this is a hint but when I add the following observer:

void MyCallBack (CFNotificationCenterRef center,
                 void *observer,
                 CFStringRef name,
                 const void *object,
                 CFDictionaryRef userInfo)
  NSLog(@"name: %@", name);
  NSLog(@"userinfo: %@", userInfo);


I receive all the notifies.

Could this be related to if Carbon or Cocoa is used?

I use Cmake to generate my projects so maybe a flag is not correctly set.



Maybe. Like I say, if you've got a custom build and are bootstrapping things your own way then I can't really help much.

I am aware of that but no worries.

After comparing the different code paths again I noticed that the Macintosh requires initialiseNSApplication() to be called which I missed.

Things are working now as expected.

Thanks again for the help.