LeakedObjectDetector hits before systemRequestedQuit is called

General JUCE discussion
1

Hello,

 

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().

 

Thanks

Dan

2

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.

3

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.

4

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.

https://www.dropbox.com/s/tgvul6jj1kfgxeu/callstacks.jpg?dl=0

 

Thanks

Dan

5

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?

 

Thanks
Dan

6

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.

7

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?

8

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

9

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.

10

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

11

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);
}


        CFNotificationCenterAddObserver(CFNotificationCenterGetLocalCenter(),
                                        NULL,
                                        MyCallBack,
                                        NULL,
                                        NULL,
                                        CFNotificationSuspensionBehaviorDeliverImmediately);

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.

 

Thanks
Dan

12

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.

13

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.