In order to reproduce, start a new empty project in Dorico, on macOS. Click on the ‘Play’ button in Dorico (upper left corner), click on the ‘+’ button in the ‘VST Instruments’ pane on the right of the interface , add AudioPluginDemo twice.
Save the project, close it. Quit dorico, restart Dorico load the project a few times, the crash happens very quickly here. With AudioPluginDemo (build on latest develop JUCE branch) the call stack do not show much:
I’m unable to repro this on the very latest develop (73523cd, Dorico 3.5.12, macOS 10.15.7).
The crashes you’re seeing look like they might be caused by a refcounting bug. There was a short window of time between the 13th of May (52e6c4f) and the 21st of May (2f04d6a8) where JUCE was incorrectly doing manual refcounting on a smart pointer in one of the VST3 SDK classes. If you were using a custom version of the VST3 SDK with a copy of JUCE from before the 21st of May, there’s a chance you may have run into the same issue. Are you able to reproduce the issue with a copy of JUCE from after the 21st of May?
May I also bring up this topic again @reuk ?
As user jpo already mentioned, in the Dorico 5area I also see this crash on quit bug. Here is an example stack:
0 Symbol was not found (0 com.hofa.IQReverb 0x000000011dda7ca3 juce::JucePluginFactory::~JucePluginFactory() + 147)
1 Symbol was not found (1 com.hofa.IQReverb 0x000000011dda74c0 juce::JucePluginFactory::release() + 32)
2 Steinberg::FModule::onUnload()
defined in: ...890/b/lib.frame-base/source/module/fmodule.cpp:643
line table: lib.frame-base/source/module/fmodule.cpp:648 (start line: 643)
3 ?
additional inline call: Steinberg::FModuleBase::getProcAddress(char const*)
caller: /Users/buildserver/Builddata/re/444599890/b/lib.frame-base/source/module/fmodule.cpp:307
line table: lib.frame-base/source/module/fmodule.cpp:186 (start line: 181)
4 ?
additional inline call: Steinberg::FModuleBase::~FModuleBase()
caller: /Users/buildserver/Builddata/re/444599890/b/lib.frame-base/source/module/fmodule.cpp:593
line table: lib.frame-base/source/module/fmodule.cpp:64 (start line: 63)
5 Steinberg::FModule::~FModule()
defined in: ...890/b/lib.frame-base/source/module/fmodule.cpp:590
As said, this is just an example, There are other plug-ins that crash in the same way. Also EastWest’s Opus is crashing Dorico’s audio engine on quit.
I’d be happy to help and find out together what’s going on there.
Cheers,
Ulf
Hi @reuk , please excuse me, I know that bumping is not welcome, but I did not get any reaction so far. I forgot to mention that I am one of the Steinberg devs and it is odd that I can only tell our customers, that it is a refcount problem in Juce, so I’d like to help to fix the issue by any means.
Best regards, Ulf
Having investigated this issue, I believe this to be a bug in Dorico.
Dorico calls IPluginFactory3::setHostContext() on the JUCE plugin factory. In the implementation of this function, we increment the refcount on the IHostApplication pointer, and store it.
When Dorico’s audio engine quits, it calls release on the JUCE plugin factory. The plugin factory is still holding a pointer to the IHostApplication, and calls release on this pointer. However, at this point, the IHostApplication has already been freed (incorrectly, because we still hold a reference to it), and the program crashes.
To fix this issue, Dorico must ensure that the IHostApplication object is still alive at the point where it attempts to release the IPluginFactory3. Another approach might be to call setHostContext again, passing nullptr, just before destroying the IHostApplication object.
I’ve created a topic to track this issue on Dorico’s side here:
Hi @reuk , to give feedback on this topic, actually you were right, it was a fault on the VSTAudioEngine side, but we have fixed it now.
And don’t wonder, no, it did not take that long to fix it, we just did not have it in focus because of other, more important work. Once looking deeper into the code and debugger, it became quickly clear what went wrong and how to fix.
