BUG? MouseInputSource <leaks> when quitting GUI app with an open PopupMenu

I don’t know if this is a bug, or something I’m doing wrong (likely the latter). But I am putting up PopupMenu from a TextButton using a lambda, like this:

    menuButton.onClick = [this] {
        PopupMenu menu;
        menu.addItem(1, "item 1");
        menu.addItem(2, "item 2");
        int sel = menu.show();
        if (sel)
        //do stuff


If I quite the app with the popup open, quite often I get this:

*** Leaked objects detected: 3 instance(s) of class MouseInputSource
JUCE Assertion failure in juce_LeakedObjectDetector.h:90

This is on Mac OSX Mojave in a gui app. I would assume JUCE is supposed to handle this, but maybe not. Any ideas? Thanks.

I guess, it’s because the menu.show() created a modal loop, that didn’t finish when the app closes down.

Maybe calling the static PopupMenu::dismissAllActiveMenus() in the quit command helps.
I have a hunch that this is already been called though, but has no chance to finish, since it is only next in the message queue.

But worth a try…

Thanks for the suggestion. I tried it but it doesn’t fix the problem. The popup menu stays open even after that is called, then it hits the assert.

This really seems like a JUCE bug? Any comment from the JUCE developers?

Or do I actually have to launch every popup asynchronously with a callback in order to avoid this? That seems very wrong…

on the contrary, that’s exactly the suggested approach to follow.
Bear in mind that there are platforms where modal loops aren’t even possible.

But thanks to the advancements in latest C++ standards, providing a callback is no more that difficult thanks to lambdas

1 Like

OK, I just played around some and it’s NOT that difficult to do it asynchronously with the lambda.

But someone else just told me (privately):

The memory-leak is a non-problem, since it only occurs on shutdown, hence won’t be cumulative. You can just ignore it.

Is that true, basically?