Crash in Linux VST Plugin Window

Audio Plugins
1

There’s a potential crash if a VST plugin window is opened and closed quickly in the Linux hosting.
This line will crash on the callback as the this pointer is now dangling: https://github.com/juce-framework/JUCE/blob/02bbe31c0d2fb59ed32fb725b56ad25536c7ed75/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp#L2931

Changing it to this should fix it:
MessageManager::callAsync ([sp = SafePointer<VSTPluginWindow> (this), this] { if (sp != nullptr) componentMovedOrResized (true, true); });
or
MessageManager::callAsync ([sp = SafePointer<VSTPluginWindow> (this)]() mutable { if (sp != nullptr) sp->componentMovedOrResized (true, true); });
I’m not sure what style is best tbh.

2

Thanks for fixing these but is there any chance they could get cherry picked on to develop?

I’m a bit worried if I point pluginval at the juce6 branch it will stop building when the branch disappears…

3

Yes, will put the first commit onto develop now - thanks for the reminder! The second only applies to some changes that were made on the juce6 branch though so no need for it to go on develop.

4

Ok. Interesting though I was seeing a deadlock on the Linux plugin hosting when trying to open a plugin window and dispatch the message loop. I was wondering if the second change was actually a fix to that…

5

It was a fix needed after this commit on the juce6 branch which removed the ScopedXDisplay from the SharedMessageThread. We need to initialise the X display here so adding the XWindowSystem::getInstance(); line to get the XWindowSystem singleton fixes it.

If you’ve got some code which reproduces the deadlock on develop then we can take a look.

6

Ok thanks. I’ll see if there’s a test case I can create.