Memory leak when hosting vst3 plugin instances

Audio Plugins
13

Hello,
digging up this thread as I’m creating a DAW, and getting into this issue.
While it’s not a “big” deal, this makes it very inconvenient when testing the software to always have memory leak notices when closing, especially when you’re looking for potential other memory leaks.

Anyway, I found a workaround to force cleaning VST3HostContext pointers even if the plugin is not properly doing it. IMHO, handling it on the JUCE side is the only realistic way to deal with this issue, as the other solution would be to contact all VST devs and tell them to modify their code…

I’m not putting a Pull Request on the JUCE github as the PR list is giant and my previous PRs have still not been processed.
Also, this is a bit dirty and I’m sure jules will have plenty of remarks before this is getting proper enough for official JUCE code :slight_smile:

juce_VST3PluginFormat.cpp, line 3320 :

    VST3HostContext* context = new VST3HostContext();
    int numRefAfterDelete = 0;
    {
        ComSmartPtr<VST3HostContext> host(context);
        DescriptionLister lister(host, pluginFactory);
        lister.findDescriptionsAndPerform(File(fileOrIdentifier));
        results.addCopiesOf(lister.list);

        numRefAfterDelete = host.releaseAndGetRefCount();
    }

    if(numRefAfterDelete > 1) delete context; //ref should only be one, otherwise this will lead to a memory leak

And added the method ComSmartPtr::releaseAndGetRefCount() in juce_VST3Common.h

int releaseAndGetRefCount()
{
    int result = 0;
    if (source != nullptr) result = source->release();
    source = nullptr;
    return result;
}

While I don’t think this is the real way to handle it, getting a method to know the ref count of a ComSmartPtr’s source can be interesting to check this kind of behaviour and ensure proper cleanups.

2 Likes