No, here is processor code if you want hpp and cpp.
Can you show me the full stack trace?
The host calls (on the Audio thread I guess) the method tresult PLUGIN_API process (Vst::ProcessData& data) override from Juce_VST3_Wrapper.cpp, l. 2101 and then you have the full stack that I wrote above.
I can reproduce the bug and give you the stack for the other threads if you want.
You are not mixing different versions of JUCE code?
No I’m sure. I use JUCE as a submodule in my git project and I use relative paths in the projucer.
juce_VST3_Wrapper.cpp, l. 1320 is at the top of your stack (bypassParam->getValue()) but that’s not really a place a crash could happen (if bypassParam is not a valid pointer it would crash insidegetValue and not at the call-site). Are you sure there isn’t any stack frame on top of juce_VST3_Wrapper.cpp, l. 1320?
@Pierre does the crash happen if you don’t add any parameters in the AudioProcessor?
@fabian what would happen if someone added a parameter that had the parameter id of the default bypass parameter but didn’t override getBypassParameter()? Could that cause an issue here?
Hmmm, I cloned your code, built the CamomileFx plug-in and loaded it in Reaper and all seems fine here. I can’t really seem to reproduce this crash - anything specific I need to do in reaper.
No, I run Reaper using Xcode. The screen shot that I sent was made using a single track with a single instance of the VST3 version of the plugin.
I guess I should have told you that the crash is not systematic. The issue is on the more recent dev branch and I use a lot of different Pure Data patches (that are not online) to test the different features.
As the bug appearead with this Juce update that seems related I assumed that it could be a Juce problem. But after your remarks on the stack (and the tests with Juce Plugin host that works well) I think it must be in fact a Reaper problem. If the processor of the parameter is NULL, it could be that Reaper accesses the parameter while the plugin is not fully initialized. Do you think that if the initialization is too slow, it could cause the crash? On the dev branch, I’m also testing the multichannel and the side-chains do you think this could be related to the crash?
I can send you Pure Data patches but I guess this will be really time consuming for you to set up everything to reproduce the crash. Perhaps I should continue my investigation on my side and keep you informed, especially if I’m the only one that encounter this crash…
Anyway, thanks a lot for your help, I really appreciate ! And thanks for your comment on the plugin
The processor member variable of the bypass parameter is expected to be NULL. This has nothing to do with the crash you are seeing. Can you run your plug-in (with different pd patches) with the address sanitizer enabled in both your plug-in and the plug-in host? Maybe you have some use-after-free issues in your plug-in.
I can’t test anything in Reaper using the address sanitizer, it blockes at startup even with an empty project and with all my plugins uninstalled… I can retry next week on another computer. Anyway, I pulled the last develop branch of JUCE and now everything works fine again! I explored a bit the commits and the only one that seems related is yours 125c562 but I don’t understand how this could have solved the problem…
This bug is even more puzzling that an inquiry of Scooby-Doo!
