Bugzilla – Bug 1257
VST Amplio2: Crash after enabling or in real-time playback.
Last modified: 2018-08-20 11:46:10 UTC
Regression on 2.0.5 (apparently). From 2.0.6 onwards, Amplio2 is prone to crash Audacity if enabled in the old plugin registration dialogue before Audacity launch, or after enabling it in the new Plug-in Manager. If 2.0.6 managed to load Amplio2, it was safe to use. The crash in use only started when using Real Time playback in Audacity 2.1.0.
If the Ambience bug 1242 is P2 on the grounds it did not crash before, then this should be P2, so promoted. These two bugs should have the same grade, whatever it is.
If the fix for bug 1242 is reverted, the crash on playback happens with the same call stack. Very likely the same problem then. The crash during enabling, however, is not yet explained.
https://github.com/audacity/audacity/commit/f0cbda835e1853470255786fa90287af54f75b9f I suspect the crash that happens sometimes when enabling the plugin, is because of a timing-dependent multithreading bug in the amplio2 library itself, which appears to be compensated if Audacity sleeps briefly at the right point. The crash was regularly reproducible for me on Windows 8, but only in release builds. Crash happens when the main thread is in LadspaEffectsModule::RegisterPlugin, though this effect is really VST -- but we check whether it is LADSPA by loading and looking for an entry point. Crash happens in a worker thread that is still attempting to execute code in the Amplio2 library after is has been unloaded at lib.Unload(). My suspicion is that the DllMain of Amplio2 has a bug, involving creation of threads when the process attaches, and failure to terminate those threads at process detach, when that occurs too quickly after attaching.
Thanks Paul for the explanations and fixes. Tested on Win 7 and Win 10 without any crashes. I played a 1 GB-sized video in VLC while enabling Amplio2, which pushed CPU usage to 80%.