I’ve heard mysterious reports from some of our customers where Ableton 10 and even 11 will crash upon project load when our plugin is present. Instantiating the plugin doesn’t cause a crash, and the issue only seems to effect the AU version. This leads me to think that somethings wrong in JUCE itself, as there’s nothing that changed in our code between VST3 and AU versions.
I’m thinking that a recent Ableton update started this issue but I haven’t been able to determine which one beyond the fact that the issue started cropping up in February. My best guess is 10.1.30
The worst part of all of this is that I haven’t been able to replicate it on my end, even with the exact same Ableton version as my customers.
Any ideas of where to even begin on this? Thanks!
If you could make a build for someone who can replicate the problem, and have that build not strip the symbols for. the release build, then you could examine the crash log and see the call stack for the thread that crashed. (Or, if you saved the build and its .dsyim file for a build that the crash happened with, you could “symbolicate” it and see that information as well.)
1 Like
I also managed to get some crash logs from a user which show an EXC_BREAKPOINT (SIGTRAP) exception:
Crashed Thread: 0 MainThread Dispatch queue: com.apple.main-thread
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [23215]
Application Specific Information:
Performing @selector(menuItemWasSelected:) from sender NSMenuItem 0x600002cfce40
Thread 0 Crashed:: MainThread Dispatch queue: com.apple.main-thread
0 com.AberrantDSP.SketchCassetteII 0x000000018d1cfbf5 SketchCassetteAudioProcessor::SketchCassetteAudioProcessor() + 30037
1 com.AberrantDSP.SketchCassetteII 0x000000018d1a4305 JuceAU::JuceAU(ComponentInstanceRecord*) + 213
2 com.AberrantDSP.SketchCassetteII 0x000000018d1b47ae APFactory<AUBaseLookup, JuceAU>::Construct(void*, ComponentInstanceRecord*) + 14
3 com.AberrantDSP.SketchCassetteII 0x000000018d1beb48 ComponentBase::AP_Open(void*, ComponentInstanceRecord*) + 72
4 com.apple.audio.toolbox.AudioToolbox 0x00007fff3d50f8f8 APComponent::newInstance(unsigned int, bool, void (ComponentInstanceRecord*, int) block_pointer) + 986
5 com.apple.audio.toolbox.AudioToolbox 0x00007fff3d50f368 __AudioComponentInstanceNew_block_invoke + 88
6 com.apple.audio.toolbox.AudioToolbox 0x00007fff3d50f212 Synchronously + 106
7 com.apple.audio.toolbox.AudioToolbox 0x00007fff3d50f088 AudioComponentInstanceNew + 203
This makes it seem like the crash is happening in our processor, though I can’t figure out where or why
Yep, looks like it’s in your constructor when it happens. Is your Processor’s constructor calling any overridden virtual functions, which might not call the correct function because it’s not fully constructed yet? Or perhaps referring to any static or global variable which might not get initialized in the order you expect?
I saw someone mention here that they thought another PACE-protected plugin that was present was causing this kind of error (due to code that tries to prevent debugging, I assume). Was that you? Not sure if that’s a red herring, but just tossing out ideas here.
Oh, and to be clear, this is happening when opening a project that had your AU plugin instantiated in it when saved? Or…? (The term “on boot” is a little confusing in this context.)
Nah that wasn’t me, and yes I meant when opening a project that had the AU plugin instantiated in it when saved.
Going over our constructor to look for any of the culprits you mentioned. We don’t call any overridden virtual functions, we do reference a number of globals to initialize their values, and there’s one instance where we initialize a global, then later reference it to initialize another. Could that be causing problems?
It’s funny since I haven’t heard of this issue popping up in any other DAW, so it being something in our constructor going wrong is surprising to me.
EDIT: I was mistaken, we actually do not reference any globals
Order-of-initialization could indeed cause problems. And the order can differ depending on how the plugin is instantiated, I think. That may or may not be the issue, but your code should definitely be written to handle arbitrary initialization order of global or static variables. I try to not use globals anywhere in my plugins, if at all possible, since they’re shared between plugin instances (when the plugins are run in the same process space, at least, which differs between DAWs). The only exception to that is globals that never change (such as a list of strings representing the different scales, note names, etc.).
1 Like
Ah my mistake! We actually aren’t using any globals after all, I mistook some of our Processor member variables as globals when I was perusing the constructor.
1 Like
