VST3/CLAP wrappers fail to call their internals' drop glue when destroyed

[estroBiologist]

When removing/destroying an instance of a VST3/CLAP plugin made with nih-plug (using nih-plug-egui for the UI) inside a host DAW, the plugin's drop glue consistently fails to run. After some debugging, I was able to track this down to an incorrect Arc refcount in the wrapper code. This leaks an arbitrary amount of memory every time - in the case of my own sampler plugin, anywhere up to hundreds of megabytes.

Tested on FL Studio 2024 and Reaper v7.40 using VST3 and CLAP. Both print an equivalent nih_debug_assert_eq!() failure:

VST3: Debug assertion failed: Arc::strong_count(&self.inner) != 1 inside <Vst3Wrapper as Drop>::drop(&mut self)

CLAP: Debug assertion failed: Arc::strong_count(&this) != 1 inside unsafe extern "C" fn destroy(plugin: *const clap_plugin)

In the case of CLAP, I was able to check the refcount at the point of the assertion failure:

The problem still occurs if the plugin window is never opened.

[estroBiologist]

Likely related:

In the VST3 wrapper, bg-thread fails to shutdown when the Plugin instance is destroyed, blocking on tasks_receiver.recv() forever and causing an access violation if the host unloads the plugin DLL (which FL Studio does when there are no more instances of the plugin in memory).

I was gonna submit a separate issue, but this definitely seems related the more I look into it. The CLAP wrapper stores the BackgroundThread handle separately from its plugin_data member, which means it gets dropped properly when the plugin instance is destroyed. The VST3 wrapper stores everything inside Arc<WrapperInner>, meaning none of it gets dropped properly and the thread never receives the "sender disconnected" signal from the EventLoop's background_thread member.

All the more reason to consider this a pretty critical bug, IMO.