Hosting a VST Plugin, crashes on Restore (Mac)


#1

Hi all,

I’m running the plugin host on Mac OSX 10.7 ( 32-bit) and loading a juce VST plugin into it, also built on Mac 32-bit OSX 10.7. Both the plugin and the host works fine on mouse clicks and processes.

My problem is that the host crashes when it is minimized and then restored. I tried setting up the debugger on the plugin host solution, and narrowed it down to juce_VSTPluginFormat.cpp:

void removeView (HIViewRef) { if (owner.isOpen) { owner.isOpen = false; owner.dispatch (effEditClose, 0, 0, 0, 0); owner.dispatch (effEditSleep, 0, 0, 0, 0); } }

It seems that the plugin is deleted when the host is minimized and that change is picked up in juce_mac_CarbonViewWrapperComponent.h :

[code]void componentVisibilityChanged()
{
if (isShowing())
createWindow();
else
deleteWindow();

    setEmbeddedWindowToOurSize();
}[/code]

juce_mac_CarbonViewWrapperComponent.h :

[code]void deleteWindow()
{
removeView (embeddedView);
embeddedView = 0;

    if (wrapperWindow != 0)
    {
        NSWindow* ownerWindow = getOwnerWindow();

        if ([[ownerWindow childWindows] count] > 0)
        {
            [ownerWindow removeChildWindow: carbonWindow];
            [carbonWindow close];
        }

        RemoveEventHandler (eventHandlerRef);
        DisposeWindow (wrapperWindow);
        wrapperWindow = 0;
    }
}[/code]

I was looking at other threads in the Juce forum and stumbled across this : http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=10168&hilit=plugin+goes+black

The changes that Jules made in regard to this thread is to not destroy the plugin when the host is minimized in windows. Making that change in Mac kinda fixed my problem as well:

juce_VSTPluginFormat.cpp:

[code]class InnerWrapperComponent : public CarbonViewWrapperComponent
{
public:
InnerWrapperComponent (VSTPluginWindow& owner_)
: owner (owner_), alreadyInside (false)
{
}

    ~InnerWrapperComponent()
    {
        owner.dispatch (effEditClose, 0, 0, 0, 0);                                        //Delete the plugin Window when the host closes. 
        deleteWindow();
    }

    HIViewRef attachView (WindowRef windowRef, HIViewRef rootView)
    {
        owner.openPluginWindow (windowRef);
        return 0;
    }

    void removeView (HIViewRef)
    {
        if (owner.isOpen)
        {
            owner.isOpen = false;
            //owner.dispatch (effEditClose, 0, 0, 0, 0);                      //omit deletion of the plugin Window. 
            owner.dispatch (effEditSleep, 0, 0, 0, 0);
        }
    }[/code]: 

I’m still a newbie so I’m not sure whether this is necessarily the solution to the problem, so any advice on this from Jules and others is appreciated! BTW, I updated JUCE about 2 months ago, so am not sure if this is solved somewhere else but AFAIK the files in question are the latest from the GIT repository. Updating the whole JUCE again would mean integrating those changes which would take some time! :expressionless:


#2

Thanks… Nice try, but I tried a few plugins, and that change seems to break them when you hide/re-show them.


#3

Hmm, I tested a few JUCE plugins myself with this change and it seems to work…Jules could you tell me which plugins you used? The ones that we developed in JUCE for Mac crashed for the same problem when we loaded it into the host…I couldn’t find out if there’s an alternative to it, because the crash happens deep in the code. Here’s the crash report when the host is restored:

[code]Crashed Thread: 0 Juce Message Thread Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000e0509670

VM Regions Near 0xe0509670:
CG shared images 00000000c4966000-00000000c496e000 [ 32K] rw-/rw- SM=SHM
–>
Submap 00000000ffff0000-00000000ffff1000 r–/r-- process-only submap

Application Specific Information:
objc_msgSend() selector name: isKindOfClass:

Thread 0 Crashed:: Juce Message Thread Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x97fd4c07 objc_msgSend + 23
1 com.apple.AppKit 0x921fbef1 -[NSWindow setInitialFirstResponder:] + 62
2 com.apple.AppKit 0x922211bd -[NSWindow _setUpFirstResponder] + 48
3 com.apple.AppKit 0x9222117e -[NSWindow _setUpFirstResponderBeforeBecomingVisible] + 57
4 com.apple.AppKit 0x9221f5f9 -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 1287
5 com.apple.AppKit 0x9221f0e6 -[NSWindow _doOrderWindowWithoutAnimation:relativeTo:findKey:forCounter:force:isModal:] + 79
6 com.apple.AppKit 0x927b0cba -[NSWindow _unhideChildren] + 406
7 com.apple.AppKit 0x92056152 -[NSWindow _hideAttachedWindows:findKey:] + 95
8 com.apple.AppKit 0x927b4cd1 -[NSWindow(NSWindow_Theme) showDeminiaturizedWindow] + 134
9 com.apple.AppKit 0x927b5151 _NSFinishRestoreFromDock + 325
10 com.apple.AppKit 0x9205d61a _NSCoreDockMessageReceive + 931
11 com.apple.HIToolbox 0x9519a990 DockCallback(unsigned long, unsigned int, void*, void*) + 2471
12 com.apple.HIServices 0x92fa21c0 _DCXMaximizedWindows + 62
13 com.apple.HIServices 0x92fca8d0 _XMaximizedWindows + 115
14 com.apple.HIServices 0x92f92017 mshMIGPerform + 504
15 com.apple.CoreFoundation 0x9646c0a5 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION + 53
16 com.apple.CoreFoundation 0x9646bcd2 __CFRunLoopDoSource1 + 146
17 com.apple.CoreFoundation 0x964a19c6 __CFRunLoopRun + 2038
18 com.apple.CoreFoundation 0x964a0d6a CFRunLoopRunSpecific + 378
19 com.apple.CoreFoundation 0x964a0bdb CFRunLoopRunInMode + 123
20 com.apple.HIToolbox 0x94efe8aa RunCurrentEventLoopInMode + 242
21 com.apple.HIToolbox 0x94efe619 ReceiveNextEventCommon + 374
22 com.apple.HIToolbox 0x94efe494 BlockUntilNextEventMatchingListInMode + 88
23 com.apple.AppKit 0x92163a5a _DPSNextEvent + 724
24 com.apple.AppKit 0x9216328c -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 119
25 com.apple.AppKit 0x921596dc -[NSApplication run] + 855
26 com.rawmaterialsoftware.pluginhost 0x00224718 juce::MessageManager::runDispatchLoop() + 312 (juce_mac_MessageManager.mm:233)
27 com.rawmaterialsoftware.pluginhost 0x003f5b88 juce::JUCEApplication::main() + 696 (juce_Application.cpp:244)
28 com.rawmaterialsoftware.pluginhost 0x003f5c8f juce::JUCEApplication::main(int, char const**) + 79 (juce_Application.cpp:299)
29 com.rawmaterialsoftware.pluginhost 0x00005750 main + 64 (Application.cpp:161)
30 com.rawmaterialsoftware.pluginhost 0x00002f85 start + 53[/code]


#4

A couple of Waves ones.

TBH I’d recommend not allowing the plugin window to be minimised in your host. I don’t think any of the main DAWs have minimise buttons, so it’d be unrealistic to assume that all plugins will be robust when that happens.


#5

Thanks for the quick reply Jules…I suppose you’re right, I’ll just disable the minimize button in the host then :slight_smile: thanks!


#6

Hi again Jules,

I’ve got another problem this time…When I Hide the plugin host (from the mac menu bar) and then restore it, the plugin disappears from the host…i.e. the window remains open, but the plugin inside it disappears…It doesn’t crash or hit an assert anywhere in the code when I debug it, and I can’t find a place to put a breakpoint to break when I click on “Hide Plugin Host”…any ideas?? :frowning:


#7

Sorry, can’t reproduce that… Maybe just a rogue plugin?


#8

Hi Jules,

Coming back to the problem at hand…I got the latest from the git repository, and did a fresh build of Juce Plug-in Host and JuceDemoPlugin. Suppose I load the juceDemoPlugin into the Plug-in Host(with the GUI open). When I Hide the host (from the mac menu bar) and then restore it, the plugin disappears… I’m running the application on a mac OSX 10.8.

I came across windowVisibilityBodge in juce_carbonVisibility.h. It seems that the NSWindow is made hidden when the Hide command is called, but I couldn’t see any callback for when the plugin is restored…