Closing multiple (10+) instances of a plugin causes hangs

We’ve released Structure and are having an issue with it hanging the users DAW when it closes. Structure is a plugin that the user will have on every single track so it can reach up to 30-40 instances. On close of the DAW or session with more than 10 instances, it hangs, sometimes up to 5 minutes. The destructor is being called, at the same time for all instances. Does anyone have a any idea how we can stagger the calls for the destructor on such a large number of instances?

Is there something you’re doing in the destructor (explicitly or implicitly) that could be causing the problem. E.g., something to do with a shared state between instances?

You’ve not got a modal loop running inside your plugin anywhere, have you? If you did something silly in the destructor like e.g. pop up a dialog box and run it modally, then while it’s running you could expect recursive calls to other destructors

@martinrobinson-2 a shared state possibly. We have a tcp listener, a button that communicates with all instances and sets a mode to on, will see if that is hanging about.

@jules nothing modal

Can you re-produce this with the “audio plugin demo” or any other plug-in demo in “JUCE/examples/PluginSamples”?

Hi Fabien

Have ran a test with the NoiseGate and AudioPlugin examples, both are fine. It is something lingering in our code that we are tracking down. Will post up our findings just incase it helps others in the future

I know it’s been closed off but I’ve eventually found the cause for this. In juce_InterprocessConnection.cpp lines 117-130

void InterprocessConnection::disconnect()
{
    thread->signalThreadShouldExit();

    {
        const ScopedLock sl (pipeAndSocketLock);
        if (socket != nullptr)  socket->close();
        if (pipe != nullptr)    pipe->close();
    }

    thread->stopThread (4000);
    deletePipeAndSocket();
    connectionLostInt();
}

changing line 127 to the following worked.

thread->stopThread (10);

Not sure what the knock on effect of this is, but for us it has resolved the issue. Would there be a case to get this amended in a future version?

Reducing the timeout will just mean that the thread will get forceably killed, leaving all kinds of mutexes and memory in an undefined state. That’s BAD! as Trump might say if he was tweeting about this.

Not sure why the connection objects are struggling to shut down, but perhaps you’re creating dozens of them? That’s probably not a good idea, and maybe you should have a single, shared InterprocessConnection for all your plugins to use?

1 Like

Haha!

Ok I’ll have a dig about and see what I can find lurking. Unfortunately, this was a project that was outsourced and the other dev is no longer available.