MessageManagerLock deadlock juce_VST_wrapper (Premiere CS6)

Audio Plugins
1

I have been getting some issues with my 64 bit VST in Adobe Premiere CS6 on Win7. (Curiously this issue isn’t reproducable on win8).

From the second time you open Premiere and try to open the interface of the plugin it deadlocks and freezes Premiere.
The problem seems to be caused because Premiere is caching a instance of the plugin on the 1st load. (also getting a leaked instance of ‘class JuceVSTWrapper’ in debug mode.)

When you change a value in adobes cache in the registry to ‘not’ cache the plugin at startup the problem is gone. This forces it to reload the plugin from disk. But you will need to do this every time before you start it. (Premiere auto sets it back on start up). So this isn’t a solution unfortunately.

This is the call stack when it deadlocks when you open the UI:

[code] ntdll.dll!00000000775efefa()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
KernelBase.dll!000007fefd7210ac()
MyPLugin-x64.dll!juce::WaitableEvent::wait(const int timeOutMillisecs=20) Line 101 + 0x12 bytes C++
MyPLugin-x64.dll!juce::MessageManagerLock::init(juce::Thread * const threadToCheck=0x0000000000000000, juce::ThreadPoolJob * const job=0x0000000000000000) Line 286 + 0x1b bytes C++
MyPLugin-x64.dll!juce::MessageManagerLock::MessageManagerLock(juce::Thread * const threadToCheck=0x0000000000000000) Line 248 + 0x12 bytes C++

MyPLugin-x64.dll!JuceVSTWrapper::dispatcher(int opCode=13, int index=0, __int64 value=0, void * ptr=0x000000000012dc80, float opt=0.00000000) Line 1175 + 0xc bytes C++
MyPLugin-x64.dll!AudioEffect::dispatchEffectClass(AEffect * e=0x000000001598f800, int opCode=13, int index=0, __int64 value=0, void * ptr=0x000000000012dc80, float opt=0.00000000) Line 33 C++
AudioFilterHost.dll!0000000008d8ca81()
AudioFilterHost.dll!0000000008d8e527()
HandlerVSTEditor.dll!000000000c8b9c10()
HandlerVSTEditor.dll!000000000c8b52e0()
HandlerVSTEditor.dll!000000000c8b5927()
ASLMessaging.dll!000000000257fe6d()
Premiere.dll!00000000074a08f6() [/code]
Traced down to the “const MessageManagerLock” in the ‘effEditGetRect’ option of the dispatcher function in juce_VST_wrapper.cpp

else if (opCode == effEditGetRect) { checkWhetherMessageThreadIsCorrect(); const MessageManagerLock mmLock; // <-- deadlocks

With a search on ‘MessageManagerLock and deadlock’ on this forum I read :

Which seems to be the case here…
Jules answer was:

If this is true, should MessageManagerLock be replaced in the VST wrapper?
How should i do this? TBH im not that comfortable messing with the core files of juce.
Just to quickly check what happens; I commented out the ‘const MessageManagerLock mmLock’. The problem remains in premiere, but noticed the debug version breaks on CHECK_MESSAGE_MANAGER_IS_LOCKED in juce_Component.cpp. So i guess these should be replaced with a mutex that is stored in the vst wrapper…?

I hope someone can shed some light on this and help me in the right direction.

2

Really no one? :frowning:

3

Confirmed the bug with the default Juce Demo Plugin (Git bleeding edge) in x64 configuration MSVC2008. in Premiere CS5.5 and CS6.

4

Sorry, didn’t see your post.

I guess Premiere must be trying to open the UI on a non-UI thread - it’s a total PITA when hosts do that, but a couple of other one do it so there’s a horrible workaround in the checkWhetherMessageThreadIsCorrect() function - I guess that that function just needs to be extended to check for Premiere as well, e.g.

static void checkWhetherMessageThreadIsCorrect() { if (getHostType().isWavelab() || getHostType().isCubaseBridged() || getHostType().isPremiere()) {

5

OMG Thank you Thank you Thank you! that did the trick! Made my day!

6

Thanks! Will check that in…

7

Hey Jules,
The problem is also there in OSX. so you might want to change it into something similar to:

#if JUCE_WINDOWS || JUCE_MAC static void checkWhetherMessageThreadIsCorrect() { if (getHostType().isWavelab() || getHostType().isCubaseBridged() || getHostType().isPremiere())

But unfortunately another problem arose with Premiere CS6 on OSX (VST). And I’m hoping you maybe have a clue whats going on
The Y position of the editor window is being shifted. The window size is ok. But most of the times the graphics are drawn too low in the window and then on top there is a big blank space. (Only a small part of the top of the interface is visible). Sometimes when you open the UI for the 1st time it is almost drawn ok (just about 5 pixels up). But if you close and reopen it is shifted far down again…
I did some probing but didn’t get any wiser… Any ideas?

8

Running that method on OSX will probably mess up a lot of other plugins, so probably needs some other kind of workaround… Sorry, no ideas spring to mind about what Premiere might be doing with the UI, it’s the kind of thing that just needs trial-and-error to figure out.

9

If I leave juce_VST_Wrapper.cpp like (latest tip):

const PluginHostType host (getHostType()); if (host.isWavelab() || host.isCubaseBridged() || host.isPremiere()) { if (! messageThreadIsDefinitelyCorrect)

then my project fails to compile with the following error:

c:\users\hemmer\documents\c++\juce\mlrvst\jucelibrarycode\modules\juce_audio_plugin_client\vst\juce_vst_wrapper.cpp(1425): error C2248: 'PluginHostType::PluginHostType' : cannot access private member declared in class 'PluginHostType' 1> c:\users\hemmer\documents\c++\juce\mlrvst\jucelibrarycode\modules\juce_audio_plugin_client\utility\juce_pluginhosttype.h(159) : see declaration of 'PluginHostType::PluginHostType' 1> c:\users\hemmer\documents\c++\juce\mlrvst\jucelibrarycode\modules\juce_audio_plugin_client\utility\juce_pluginhosttype.h(28) : see declaration of 'PluginHostType'

If I revert to the earlier version from four days ago it works fine:

if (getHostType().isWavelab() || getHostType().isCubaseBridged()) { if (! messageThreadIsDefinitelyCorrect) {

Any ideas?

10

I fixed that a couple of days ago - if you get that error, then you’re not using the latest code.

11

Great cheers works now I’ve manually updated everything!

12

I've run into this with a customer using Premeire CS 6 on Mac, using my plug-in that was built with JUCE 2.1.7.  It appears there never was a Mac solution to this problem.  Conditionally removing the mmLock altogether when under Premiere on Mac seems to have fixed the issue for the customer, and the scope is fairly limited.  Perhaps the broader question should be asked - why is JUCE trying to be the threading-cop anyways?  I ran into this same issue with earlier versions of FCP X too (maybe the same developer coded plug-in hosting for Adobe and Apple?)  Anyways, all the mmLock does is hang the the user's system - not good.  Seems like codependency to me ;)

 

Thanks-

Steve

 

13

It uses a lock there because if the host decides to call effEditOpen on a background thread, then it does could cause havoc if other GUI stuff is happening at the same time on the event thread. I can't for the life of me think why a host would be crazy enough to try to open the plugin's GUI on a non-GUI thread, but if it does, I really don't know what else if could do there to avoid a possible race condition.

14

Wouldn't it make more sense to return an error instead of freezing the user's app?

Steve

15

If it knew there was an error, it could work around the problem.

The thing is that when this method is called on a background thread, it needs to lock the message thread to avoid race conditions. I assume that the deadlock is happening because these goddamn hosts are both calling us on a background thread and also blocking the GUI thread themselves. But there's no way for the plugin to know that the host is blocking its message thread, so there's no way to know whether anything is wrong and return an error. Maybe it could use a timeout, I don't know.. TBH I'm seriously pissed off about even having to think about this, because it's such a fucking stupid thing for a host to do. It's fair enough to make a lot of calls on background threads, but not when you're trying to open the GUI, FFS.