Crash closing hosted plugin editor

I have a bug in my host where the app crashes after deleting the plugin editor. This only happens sometimes, on some systems with some plugins.
Here is a snippet from a crash report.

Process: MyHost [2365]
Path: /Applications/
Version: 1.0.0 (1.0.0)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: MyHost [2365]
User ID: 501

Date/Time: 2016-07-24 18:35:04.105 +0200
OS Version: Mac OS X 10.11.5 (15F34)
Report Version: 11
Anonymous UUID: 620A8AB0-0A19-B8C3-BEF7-9F42691CF3BC

Sleep/Wake UUID: EE920A89-3DF6-4A6B-AE76-BBAA1363846B

Time Awake Since Boot: 70000 seconds
Time Since Wake: 11000 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Juce Message Thread Dispatch queue:

Exception Codes: KERN_INVALID_ADDRESS at 0x00000000000000d0

VM Regions Near 0xd0:
__TEXT 0000000102a63000-000000010318d000 [ 7336K] r-x/rwx SM=COW /Applications/

Global Trace Buffer (reverse chronological seconds):
18446744069.972378 CFNetwork 0x00007fff8c4423cb TCP Conn 0x7fdccac61120 SSL Handshake DONE
18446744070.337456 CFNetwork 0x00007fff8c4422a7 TCP Conn 0x7fdccac61120 starting SSL negotiation
18446744070.337704 CFNetwork 0x00007fff8c440c71 TCP Conn 0x7fdccac61120 complete. fd: 10, err: 0
18446744070.337791 CFNetwork 0x00007fff8c4cf54b TCP Conn 0x7fdccac61120 event 1. err: 0
18446744070.488857 CFNetwork 0x00007fff8c43ff43 TCP Conn 0x7fdccac61120 started
18446744070.522705 CFNetwork 0x00007fff8c403bc6 Creating default cookie storage with process/bundle identifier
18446744070.522705 CFNetwork 0x00007fff8c403b5e Faulting in CFHTTPCookieStorage singleton
18446744070.522705 CFNetwork 0x00007fff8c4039ed Faulting in NSHTTPCookieStorage singleton

Thread 0 Crashed:: Juce Message Thread Dispatch queue:
0 com.WavesAudio.WaveShell-VST3.9.6.51 0x000000010b9af653 wvWavesV9_11::PluginViewManager::WCPluginViewManagerMacCocoa::GetThreadWhereViewWasCreated(WSPluginView*) + 11
1 com.WavesAudio.WaveShell-VST3.9.6.51 0x000000010b9acf1f wvWavesV9_11::PluginViewManager::ThrowIfNotInCorrectThread(WSPluginView*) + 13
2 com.WavesAudio.WaveShell-VST3.9.6.51 0x000000010b9b26dd wvWavesV9_11::PluginViewManager::HidePluginView(WSPluginView*) + 14
3 com.WavesAudio.WaveShell-VST3.9.6.51 0x000000010b963c37 WCPluginGraphicaGS::DeactivateView() + 73
4 com.WavesAudio.WaveShell-VST3.9.6.51 0x000000010b964fba WCPluginGraphicaGSOpenGL::DeactivateView() + 18
5 com.WavesAudio.WaveShell-VST3.9.6.51 0x000000010b5c7dd5 WCWaveShell_VST_GUIEditor::close() + 71
6 com.WavesAudio.WaveShell-VST3.9.6.51 0x000000010b5bffe6 Steinberg::Vst::VSTGUIEditor::removed() + 36
7 juce::VST3Classes::VST3PluginWindow::~VST3PluginWindow() (in MyHost) (juce_VST3PluginFormat.cpp:1407)
8 juce::VST3Classes::VST3PluginWindow::~VST3PluginWindow() (in MyHost) (juce_VST3PluginFormat.cpp:1405)
9 PluginWindow::~PluginWindow() (in MyHost) (PluginWindow.cpp:82)
10 PluginWindow::~PluginWindow() (in MyHost) (PluginWindow.cpp:75)

I managed to recreate the issue on my mac with a waves VST3 plugin.
My app has the plugin editor as a scopedpointer inside a component owned by a document window. When destroying the window, the scopedpointer is set to nullptr and the desctructor ~VST3PluginWindow() is called
Xcode breaks at warnOnFailure (view->removed());
It seems to me like the plugin is trying to access the window that is being deleted?
Is there a best practice for closing and freeing the editor?
I see that the example host runs the message loop after deleteing the window, I have also implemented that, but the crash happens before this.

Any input would be greatly appreciated

1 Like

Can you re-produce this with the audio plugin host? You could look at the source code of the audio plugin host to see how it’s done there.

Sorry, it was a mistake on my side

Hi AudioStrom, I’m having exactly the same bug. Did you remember what was the mistake?

That was a long time ago. But looking back at commits from that time It seems I simply made some calls in the destructor of the parent window that I should not have done, a bit over eager to clean up I guess. Just a silly, stupid mistake.
4 years later, I have learned to test these things agains the demo host, and compare the code/behaviour