Pro Tools Crashes with [d13be21] Commit (Added support for enabling/disabling sidechains in AAX).
It opens with commits before this.
Pro Tools version? OS?
Pro Tools 12.6.0 HD Dev , Windows 10
Are you using sidechains or does it crash for a “regular” plugin as well?
I am getting tester reports about a crash in the method below and I’m not using sidechains at all so I wonder if this still could be related.
AAXClasses::algorithmProcessCallback(AAXClasses::JUCEAlgorithmContext* const*, void const*)
Regular no sidechain. I’m using 6ins/6outs for 5.1 plugin. I haven’t debugged it yet so I don’t know what method is causing it. But when I roll back, it works.
I looked at the commit diff and (without extensive testing) it looks like it should not be problematic as long as there are no additional busses. Are you using multiple busses for the 6in/6outs?
No busses. Changed the channel config to {6,6}.
Every time I try to open a session with the plugin, it breaks at
Line 1515
float* const meterTapBuffers = (i.meterTapBuffers != nullptr ? *i.meterTapBuffers : nullptr);
In juce_AAX_Wrapper.cpp
Ok hopefully someone in the Juce team can look at that. All I see is that this line 1515 is called by the method I got from a testers crash-log (AAXClasses::algorithmProcessCallback(AAXClasses::JUCEAlgorithmContext* const*, void const*)) So that makes it quite likely you and my tester encounter the same crash. Unfortunately I cannot reproduce the crash on my machines.
This line was not part of the commit that broke things for you, but it is related to side-chains which were changed.
Looking at the changelog even more I believe I found the bug. This change in line 1770 (of the new version):
-- HeapBlock<AAX_CTypeID> meterIDs (static_cast<size_t> (numMeters));
++if (numMeters > 0) {
++ HeapBlock<AAX_CTypeID> meterIDs (static_cast<size_t> (numMeters));
probably leads to meterTapBuffers being uninitialized in case numMeters is 0. Unless the struct is zeroed somewhere else and I haven’t found it. Then dereferencing i.meterTapBuffers in the line 1515 leads to undefined memory access and crash. If I’m correct, JUCE team please fix this asap!
1 Like
Sorry for the delay on this. I had trouble reproducing this (and still can’t). Does my recent commit fix this? If yes, we will release a hot-fix for this.
2 Likes
thx! I am unable to confirm directly whether the fix works as I didn’t get the issue on my systems. However one of my tester had the crash. Verifying the fix works will take some time. Hopefully cocell can confirm quicker.
I’m a bit puzzled by the proposed fix. I understand checking the size is easier to read than checking against nullptr, but I’m bothered by the pointer variable still not being properly initialized in case there are no meters (which is the case for all legacy plugins). I would have preferred if just the initialization was fixed.
I can confirm that the recent commit fixed the issue.
My quick fix was setting meterTapBuffers to nullptr.
Thank you fabian. 
JUCE has no control over the initialisation of the member variables in JUCEAlgorithmContext struct. That’s all in ProTools ’ control. In the createDescriptor method we tell ProTools about the different fields in the JUCEAlgorithmContext struct and ProTools will initialise these fields correctly. In a previous version, I registered the meterTapBuffers field with ProTools as a zero-length array if there are no meters. However, this brings up an alert in the development version of ProTools warning about a zero-length field. This is why I don’t register the field anymore if there are no meters. But not registering the field means that ProTools will not initialise it - it will just be a random value, so no point in checking for nullptr.
2 Likes
Ah ok! That explains everything! As you can tell I never had to deal with AAX myself thanks to JUCE.
I just pushed a hot-fix for this on master and re-uploaded all the JUCE binaries.