Site navigation

Multithreading and PluginListWindow

General JUCE discussion
#1

Hey Jules -

Strange issue here with the messageManager and PluginListWindow. It doesn’t happen in the example PluginHost and hence is likely my problem; although it is also definitely a newish issue for me (meaning it certainly didn’t happen pre-JuceQuake … so has something to do with a revision somewhere along the way).

Anyway …

I have a VST/AU host that behaves much like the example one. Scanning is handled in the same way verbatim (using the PluginListWindow class from the example code). Lately, I started getting a crash just after the scan (as soon as I click on the “ok” dialog that mentions that a few scanned plugins appear to be plugs but don’t work properly).

There is a modal loop that is running, and it get’s stuck because something has been deallocated in the interim (see attachment).

Sometimes the object gets cleanly deallocated between calls and the program continues running as expected, having scanned successfully. However, in those instances another error appears when exiting the program …

in juce_mac_MessageManager class : line 217 in mm file

 if (oldDelegate != nil)
        [NSApp setDelegate: oldDelegate];

Which seems to indicate a previous appDelegate? That seems dangerous, and I’m not sure when/why this was created … but figure you are much more likely to know. It breaks here because the oldDelegate no longer exists, but the pointer apparently does.

Any thoughts are appreciated, as always.

#2

Hmm, that’s an interesting question. Thanks for making me re-examine that (very old!) code again, I actually think I should remove all that oldDelegate stuff, since in an app it should always be nil, and in a plugin it’s not used.

…But: its value should never have been non-nil! I’m not sure how you’d manage to get it confused like that… It could be possible if you close-down and re-initialise all the juce stuff, maybe if you’ve got some kind of recursive singleton shutdown loop going on…

Anyway, this is how it should look:

[code]- (void) dealloc
{
if (JUCEApplicationBase::isStandaloneApp())
{
[NSApp setDelegate: nil];

    [[NSDistributedNotificationCenter defaultCenter] removeObserver: self
                                                               name: AppDelegateRedirector::getBroacastEventName()
                                                             object: nil];
}

[/code]

#3

Sounds good.

Thanks for the changes, will keep you posted if the problem persists or I get anywhere in figuring it out.

#4

AHA!

During the plugin scan, we allocate/deallocate some Juce plugins … which allocate/deallocate their own MessageManagers along with Juce.

Here’s the trick … This ONLY happens if we are linking to a built lib of Juce (if I include the amalgamated.mm files the issue resolves). My guess here is that the tree is out of joint with the amalgamated files?

Included below is a debug printout - when the Juce based plugin (reverb) deallocates, there is an error hit in the MM.ccp file indicating the issue.

PS - I am on the master branch, not modules … I assume those two will merge eventually?

#5

If you use a release build, it should be impossible to get into that kind of mess. It’s only when you have a debuggable host and debuggable plugins that the linker can get its wires crossed like that.

#6

Ah yes - hadn’t thought of that - but certainly true.