I started experimenting with hosting plugins within a juce app which works very nice. I can add a VST3 plugin instance to a audio graph and display the editor in a separate window. When I close my application, however, the LeakedObjectDetector complains about a leaked instance of VST3HostContext. Looking a bit deeper I found a potential bug in VST3ComponentHolder which creates a new VST3HostContext instance in its constructor and never actually deletes it. In its destructor it just assigns nullptr to the corresponding pointer object, which is wrong in my opinion. But maybe I’m just doing the whole plugin hosting wrong and the leak is on my side, I don’t know. If I explicitly delete the instance in the VST3ComponentHolder destructor the error disappears. Can anyone please take a look and tell me if my assumption is correct? Working on mac by the way, if this is relevant. Thank you!
Did you borrow any of your implementation from the Audio Plugin Host project in the repo? that’s what you should be following for how to host a plugin.
Yes, my implementation is inspired by the example project, but less complex. For example I hard coded the file to be loaded and did not implement the plugin selection window.
I just checked with the mentioned example where the same memory leak is indicated. I am convinced now that this is a bug in VST3ComponentHolder. However, I don’t know what’s the most elegant way to fix it. Just typing
delete host; in the destructor does not seem right.
It’s not a mistake.
host is a COM smart pointer so is ref-counted.
Most likely would be that you’re leaking an object yourself which indirectly keeps a reference to that object, but haven’t got a leak detector on your own object to spot that.
As I said, the example project behaves exactly the same. But it seems like this happens only with certain plug-ins, e.g. it happens with RoughRider2, so maybe it’s a false alarm. But you are completely sure that the nullptr assignment in
~VST3ComponentHolder() is correct? When is the object actually destroyed?
Yeah, some plugins may implement the ref-count differently/incorrectly and have an out-by-one-error. We’ve seen that kind of thing happen before. But I wouldn’t worry about it (other than taking this as a hint that maybe it’s time to learn about smart pointers!)
Ok, thank you! I know a bit about smart pointers, I just did not see where in the implementation of ComSmartPtr the pointed to VSTHostContext object is destroyed if we assign nullptr before. I still don’t see it to be honest, but I will concentrate on more important things now
@jules Could you please help me understand. In the d’tor of ComSmartPtr I read
if (source != nullptr) source->release();. But source is actually nullptr due to the preceding assignment. In my understanding the ref counter is not decreased and the object is never destroyed. Where is my mistake?
Assigning any new pointer to a smart pointer will release the old one. But seriously, you’re stuck in the weeds, there’s no bug in the pointer handling!