Hi,
After updating JUCE, pluginval started crashing during our Audio Unit validation. Pluginval ends with “pluginval received Segmentation fault: 11, exiting immediately”.
I’ve traced back the crash to this commit.
I tried to compile pluginval with the latest JUCE but that doesn’t make any difference.
Does anyone have an idea of how that specific commit could introduce this crash?
Best,
Jelle
Have you tried attaching a debugger? Might also be worth adding address/thread sanitizer. Have you also tried with any of the audio plugin demos? Do they have the same problem?
Is it a crash in pluginval or your plugin?
Definitely attach a debugger to get a stack trace whilst running pluginval under it.
At what level? I just had this exact thing, and “fixed” it. So if it’s at level 3 that it bugs out I might be able to help you.
To debug, I had to make very sure that I’m launching the pluginval version that I just (Debug target!) compiled with Xcode. Then, compile my plugin from Xcode as well, then attach to pluginval process, make sure pluginval points to your just compiled build, make sure pluginval Options→Validate in-process is turned on, then run the test. If I forgot one of these steps I would always land in some assembler code.
Alright, after a debugging session, I traced the crash back to a call to updateHostDisplay() inside prepareToPlay() in our plugin.
Maybe calling updateHostDisplay() from prepareToPlay() is not safe, although this used to work for us and passed pluginval. I wonder if that JUCE commit, moving files without UI dependencies to juce_audio_processors_headless, somehow changed the behaviour of updateHostDisplay.
The crash easy to reproduce:
Create a new audio plug-in using Projucer (JUCE 8.0.12)
Call updateHostDisplay() from prepareToPlay()
Run pluginval (develop branch) with the plugin .component path as command line argument and see it crash at the end after SUCCESS logs.
My system is macOS 15.6.1 (24G90).
The crash itself is not very clear, see the screenshot below.
Do you get a more detailed stack trace if you click the “show all frames” button (funnel icon) at the top of the call stack window? If so, that might provide some more hints.
I think this might be awkward to track down if it crashes in system code - sometimes these kinds of crashes are caused by incorrect reference counting of Objective-C types, so perhaps you could try running the app under the Instruments “allocations” checker to see whether that gives you any new information.
As @anthony-nicholls mentioned earlier, it’s also a good idea to enable address sanitizer for your plugin build and the pluginval build. It’s possible that there’s a memory issue in pluginval or in the plugin, but the symptomatic crash happens some time after the memory issue first occurs.
Thanks @reuk for the suggestions.
I’ve digged a bit deeper into updateHostDisplay and figured out that it fails ONLY for the parameter info changed flag. I previously just relied on the default flags by calling updateHostDisplay().
I’ve tried all 4, see below:
updateHostDisplay(ChangeDetails().withParameterInfoChanged(true)); // Crash
updateHostDisplay(ChangeDetails().withProgramChanged(true)); // OK
updateHostDisplay(ChangeDetails().withNonParameterStateChanged(true)); // OK
updateHostDisplay(ChangeDetails().withLatencyChanged(true)); // OK
Luckily, for my plugin I just need the withNonParameterStateChanged to be set, and I can confirm it passes pluginval now, so I don’t need to further investigate this for myself.
Most debuggers allow you to trigger a breakpoint when an exception is thrown rather than when it’s caught. This might help track down the cause.
I have seen something similar before, might related. I would guess the problem is that pluginval does not call prepareToPlay on the message thread for AU. Here is a log from quite a while ago (an old JUCE 8 version, and I disable sanitizers for AU since then).
2025-03-24T21:01:40.3540790Z WARNING: ThreadSanitizer: data race (pid=13041)
2025-03-24T21:01:40.3541070Z Read of size 8 at 0x000109401230 by main thread:
2025-03-24T21:01:40.3547370Z #0 juce::AudioProcessor::getSampleRate() const juce_AudioProcessor.h:822 (pluginval:arm64+0x1000b483c)
2025-03-24T21:01:40.3548030Z #1 juce::AudioUnitPluginInstance::updateLatency() juce_AudioUnitPluginFormat.mm:1800 (pluginval:arm64+0x10090cb14)
2025-03-24T21:01:40.3549350Z #2 juce::AudioUnitPluginInstance::respondToPropertyChange(AudioUnitProperty const&) juce_AudioUnitPluginFormat.mm:2092 (pluginval:arm64+0x1009bd8c0)
2025-03-24T21:01:40.3550540Z #3 juce::AudioUnitPluginInstance::eventCallback(AudioUnitEvent const&, float) juce_AudioUnitPluginFormat.mm:2058 (pluginval:arm64+0x1009bd584)
2025-03-24T21:01:40.3551380Z #4 juce::AudioUnitPluginInstance::eventListenerCallback(void*, void*, AudioUnitEvent const*, unsigned long long, float) juce_AudioUnitPluginFormat.mm:2108 (pluginval:arm64+0x1009bd3dc)
2025-03-24T21:01:40.3552070Z #5 AUEventListener::MessagesAreAvailable() <null>:95604356 (AudioToolboxCore:arm64e+0xc6764)
2025-03-24T21:01:40.3552690Z #6 juce::JUCEApplicationBase::main() juce_ApplicationBase.cpp:277 (pluginval:arm64+0x1005558ec)
2025-03-24T21:01:40.3553280Z #7 juce::JUCEApplicationBase::main(int, char const**) juce_ApplicationBase.cpp:255 (pluginval:arm64+0x100555690)
2025-03-24T21:01:40.3553780Z #8 main Main.cpp:173 (pluginval:arm64+0x10003d2d8)
2025-03-24T21:01:40.3554000Z
2025-03-24T21:01:40.3554100Z Previous write of size 8 at 0x000109401230 by thread T5:
2025-03-24T21:01:40.3554640Z #0 juce::AudioProcessor::setRateAndBufferSizeDetails(double, int) juce_AudioProcessor.cpp:378 (pluginval:arm64+0x10060aaa0)
2025-03-24T21:01:40.3555290Z #1 juce::AudioUnitPluginInstance::prepareToPlay(double, int) juce_AudioUnitPluginFormat.mm:1267 (pluginval:arm64+0x1006a6d04)
2025-03-24T21:01:40.3555950Z #2 callPrepareToPlayOnMessageThreadIfVST3(juce::AudioPluginInstance&, double, int) TestUtilities.h:201 (pluginval:arm64+0x100092000)
2025-03-24T21:01:40.3556590Z #3 AutomationTest::runTest(PluginTests&, juce::AudioPluginInstance&) BasicTests.cpp:378 (pluginval:arm64+0x1000a7fbc)
2025-03-24T21:01:40.3557150Z #4 PluginTests::testType(juce::PluginDescription const&) PluginTests.cpp:204 (pluginval:arm64+0x10007a890)
2025-03-24T21:01:40.3557590Z #5 PluginTests::runTest() PluginTests.cpp:119 (pluginval:arm64+0x100079c74)
2025-03-24T21:01:40.3558020Z #6 juce::UnitTest::performTest(juce::UnitTestRunner*) juce_UnitTest.cpp:89 (pluginval:arm64+0x1002b5a50)
2025-03-24T21:01:40.3558760Z #7 juce::UnitTestRunner::runTests(juce::Array<juce::UnitTest*, juce::DummyCriticalSection, 0> const&, long long) juce_UnitTest.cpp:177 (pluginval:arm64+0x1002b6d74)
Do AudioUnit’s have to be initialised on the message thread?
I couldn’t find anything definitive about AU threading requirements.
I guess the other question is does juce::AudioProcessor::prepareToPlay have to be called on the message thread?
Perhaps yes for AU compiled by JUCE? Given sampleRate, latency and some other variables are not atomic in juce::AudioProcessor, perhaps pluginval should call prepareToPlay on the message thread or acquire a message thread lock.
I would have expected an assertion in juce if that was the requirement?
I would see yes but it is up to the JUCE team. In my own JUCE fork I just change those parameters, especially the latencySamples, to std::atomic to simplify the problem 
Otherwise the thread sanitizer will randomly throw errors if I call setLatencySamples later on the message thread.
