JUCE VST Plugin Editor crash in Reaper i386 OSX


#1

hi!

i experienced a problem (jassert) with following situation in Reaper (v 4.591) and the latest JUCE from git:

a double click on a plugin in the FX chain of Reaper results in opening the editor in a floating window.

having the Juce Demo Plugin (or any other Juce based Plugin with Editor) selected (therefore showing the editor in the non-floating FX window) and then double click another plugin in the FX chain results in this crash:

JUCE Assertion failure in juce_VST_Wrapper.cpp:1090
Process 14682 stopped
* thread #1: tid = 0x3b226, 0x1647a116 JuceDemoPlugin`JuceVSTWrapper::deleteEditor(this=0x11497fa0, canDeleteLaterIfModal=true) + 134 at juce_VST_Wrapper.cpp:1090, queue = 'com.apple.main-thread, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
    frame #0: 0x1647a116 JuceDemoPlugin`JuceVSTWrapper::deleteEditor(this=0x11497fa0, canDeleteLaterIfModal=true) + 134 at juce_VST_Wrapper.cpp:1090
   1087            {
   1088                PopupMenu::dismissAllActiveMenus();
   1089    
-> 1090                jassert (! recursionCheck);
   1091                recursionCheck = true;
   1092    
   1093                if (editorComp != nullptr)

this does not happen for the x86_64 version of Reaper and it does not happen in the windows version.

is this a juce problem or should i report it to the Reaper guys?

 

thanks, matthias


#2

Looks like they're trying to delete the plugin's UI during a recursive call from inside one of its own idle() callbacks.. If so, you should be able to see the recursion on the stack trace? That'd be something for the Reaper guys, as there's nothing the plugin could do to avoid silliness like that.


#3

i got an answer at the Reaper forum (http://forum.cockos.com/showthread.php?t=134109)

i tried to comment following code in juce_VST_Wrapper.mm and the problem is gone.


for (int i = 20; --i >= 0;) MessageManager::getInstance()->runDispatchLoopUntil (1);

in that file it says that this code was added to fix bugs with Live and Reaper.

i just checked with the new versions of Live and Reaper and did not experience any crash while opening/closing multiple instances of JUCE plugins.


#4

The original problem originated from REAPER unloading the VST bundle on close, while the OSX window manager would still end up referencing the NSWindow which parented the editor. 

As I posted in the linked thread above, it helps to call [pluginWindow close] when detaching from the windowRef, plus some other tweaks, as in this patch:

http://1014.org/shiz/code/juce_patch_good.txt

It doesn't completely fix all issues, but for me at least (on 10.5 and 10.9) having that patch behaves better in REAPER than without. There are still other issues when REAPER is set to unload VSTs on close, though, but that option is thankfully off by default (it was added to fix similar issues that the event-loop-running-workaround was meant to address).

I'll also look into preventing reentrancy in REAPER from plug-ins that run the event loop during effEditClose... it should be easy enough to do.

--

Ideally though, one could update JUCE to use Cocoa if the host sends an effCanDo of "hasCockosViewAsConfig", and the plug-in returns 0xbeef0000. If this happens, REAPER will pass an NSView to effEditOpen rather than a windowRef.

Thanks!

Justin

 


#5

Hi Justin, thanks for dropping by our little forum!

Interesting patch.. looks eminently sensible to me, I'll get onto that asap. And good to know about the secret canDo - anything that can avoid a few WindowRefs is very welcome.


#6

My pleasure! Here's some more documentation regarding that canDo:

http://reaper.fm/sdk/vst/vst_ext.php#osx_ext


#7

Excellent stuff, thanks!


#8

thanks for fixing that, works fine with the latest git checkout!