Probable bug in AudioProcessor/AudioProcessorParameter

I tried to implement parameters myself in AudioProcessor and crashed a couple of hosts. The bug involves overriding AudioProcessor::getNumParameters() but not getParameterText(), and implementing parameter change gestures in the GUI.

 

from the JUCE source I found on github a week ago:


const String AudioProcessor::getParameterText (int index)
{
    return getParameterText (index, 1024);
}

String AudioProcessor::getParameterText (int index, int maximumStringLength)
{
    if (AudioProcessorParameter* p = managedParameters[index])
        return p->getText (p->getValue(), maximumStringLength);

    return getParameterText (index).substring (0, maximumStringLength);
}

 

The two functions call each other recursively, resulting in a stack blow and a crash. Depending on the host, the crash might not even happen in the plugin's call stack either (FL studio crashed in FLEngine.dll at an unknown location, VSTScanner showed the correct location).

In other news, I found an efficient way to crash the VST host with cryptic error messages, just blow the stack.

The thing is that if you're not using the new parameter classes, then you MUST implement at least one of those methods.

They used to be pure-virtual, so it'd have forced you to implement it safely, but I changed that because we no longer want anyone to use them, and I added some default implementations. I guess I can find a way to add an assertion to catch the recursion and make it clear what's wrong, but it's your implementation which needs to change to make it work.

Thanks for the heads up, that's what I ended up doing. The so called bug is only bad because the crash is very randomly located. That's not on Juce, but I didn't expect a blown stack to crash the host at a random place. I'm also surprised the recursive call stack increment is not optimized out with tail recursion, which would result in a hanging thread.

I almost wrote another bug report (create file in Introjucer in random directory, move them in Visual Studio, move them in Introjucer, delete them in Visual Studio but not Introjucer, move another copy to the correct project directory with command line, Introjucer hangs), but since it involves massive noobage it will probably not be worth your time.

Thanks for Juce, it's real cool.

Thanks. I did add an assertion now, so hopefully anyone else who hits this will find it easier to see what's going on.