JACK race condition pull request


there is some flawed logic in the JUCE code that handles patching the JACK ports of the JUCE app to the ports of the selected JACK “device”.

Basically, the code iterates over the set bits of the inputChannels/outputChannels BigInteger instances, but these get modified while iterating because JACK calls back to notify that the previous channel was correctly patched.

Here is a pull request that fixes the issue:


1 Like

Thanks for taking the time to look into this issue. I just checked out the patch, and it looks like it’s based on the JUCE 6.0.1 master release. Since that release, I’ve revamped the JACK backend (see this commit) and fixed several issues to do with how JACK connections were managed. As part of this patch, I added a change which handles callbacks from JACK asynchronously, which should ensure that all port updates in JackAudioIODevice::open have completed before updateActivePorts is called.

Could you try testing the current state of develop, and checking whether it resolves your issue? I tried to repro here and everything seemed to work correctly, but perhaps you have a more reliable reproduction.

Hi thanks for your reply! My company has not moved to Juce6 yet so I can’t really test easily but I suppose this should fix the issue I encountered. Will let you now when we make the switch (which should be in the next few months)

So i’ve just updated my project to 6.0.4 and I can confirm that this issue is fixed!

1 Like