VST3 Access Violation

Audio Plugins
21

Hmm. I said earlier in this thread that it seemed like a link error. You were probably mis-linking different versions of a library or some kind of class.

22

1. Run demo host.

2. Load an instance of Vienna Ensemble VST3

3. Exit host or delete the filter

4, Crash at component->terminate(); in destructor

    ~VST3PluginInstance()
    {
        jassert (getActiveEditor() == nullptr); // You must delete any editors before deleting the plugin instance!
        releaseResources();
        if (editControllerConnection != nullptr && componentConnection != nullptr)
        {
            editControllerConnection->disconnect (componentConnection);
            componentConnection->disconnect (editControllerConnection);
        }
        editController->setComponentHandler (nullptr);
        if (isControllerInitialised)    editController->terminate();
        if (isComponentInitialised)     component->terminate(); //Crash here
        componentConnection = nullptr;

If you bypass this you get a AttributeList Leak.

Any ideas?

BTW this does not happen with 64 bit version of Vienna Ensemble and I noticed that when the Vienna VST3 instance is loaded the edtor dissappears and then reappears.

 

23

In situations like this when a plugin crashes inside its own code, and when other plugins don't crash in the same situation, then you should be telling the plugin authors about it rather than us.

Usually this kind of thing happens when the host is behaving in a way which is perfectly valid, but where a particular plugin isn't robustly written. E.g. there may be a few different orders in which the host could legitimately choose to call shutdown functions, but the plugin has only been tested in hosts which happen to do it in a particular way. Sometimes it's possible for us to make changes to our hosting code to work around problems like this, but it's impossible to know what to change without feedback from the plugin authors themselves.

24

Ok I'll contact Vienna but you know they are going to say it's Juce. You may be right that all the hosts have written around glitch. or that the hosts delete the plugin in a different order than juce.

I am and I pretty sure it's the order of objects being released. I tried changing the order of them but it still crashes what ever I do.

For now I don't release it and of course when the applicaion exists their is an Attribute List still hanging around.

Strange crash on first load of new plugin build
25

They may say it's juce's fault, and that could be true. Our hosting code could indeed be doing something silly, and all other plugins may just be lucky not to have a problem with it.

But my point is we can't debug someone else's plugin to see what's crashing it.

If they run it in a debugger and see our host doing something wrong or dangerous, then we'd be happy to fix that. But it's just not possible for us to magically discover why someone else's closed-source plugin is crashing!