Deadlock message manager lock when a plugin host another juce plugin

Linux
1

I've discovered that in a JUCE VST plugin, if i host another JUCE plugin and open its editor in an external window, a deadlock may or may not occur cause of a MessageManagerLock wait indefinately. This does not occur if i host a plugin not done in JUCE.

juce_VSTPluginFormat.cpp line 1287:

case audioMasterSizeWindow:
    if (AudioProcessorEditor* ed = getActiveEditor())
    {
       #if JUCE_LINUX
        const MessageManagerLock mmLock;
       #endif
        ed->setSize (index, (int) value);
    }
    
    return 1;

This creates a deadlock cause dispatcher function in juce_VST_Wrapper.cpp does lock the message thread when opening and closing the plugin gui...

2

Maybe you've not stripped symbols in your host, so there's some cross-linkage internally of common juce static values.

3

ah that could be, as i'm debugging so all symbols are there.

is there a way to avoid it ?

would rename the juce namespace to something else work to avoid clashes ?

4

it seems that adding -fno-leading-underscore to gcc helps.

is there a way to have Extra compiler flags for each target in Introjucer ? i would like to add the flag only in debug builds... 

5

I suspect that that only seems to help, because it'll change the names of the symbols and avoid some clashes, but that's missing the point - you really need to make sure the symbols really aren't visible externally.

6

yes, but how to do that when debugging ?

7

Well, either the host or plugin should be stripped. As long as you're only debugging one or other of them, that should be possible.