Crash on closing Studio One with AU version open?

We’re seeing a crash if the user closes Studio One 4 with the AU version of our plug-in(s) instantiated and open, IF the DAW asks whether the user wants to save the current song and the user clicks Yes. If they Cancel or click No, or if using the VST3 version, then there is no such crash. Looking at the stack, it’s in Studio One code, not ours. Our code still has a JUCE Timer thread running (and waiting) when this happens, but otherwise I don’t see anything related to our code in play. Anyone else seen this happen?

This does not happen with VST3 plugins, only Audio Units. And only in Studio One, not Logic or Ableton Live. And it’s only in one of our plugins so far. But there is no indication in our code that something might be wrong. Anyone have any ideas what might be going on? I can’t release with a known crasher, unless I can demonstrate that Studio One is actually at fault. But since it crashes outside of any of our code, and I can’t debug Studio One’s code, that’s difficult to prove.

test out this scenario with a juce demo plugin. If this still happens with a demo, it’s a JUCE issue; if it doesn’t, it’s an issue with your plugin.

It only happens with this plugin so far. But how can I possibly find out what is wrong when it crashes in Studio One, totally outside of my code, and doesn’t crash in any other host or with VST3 instead of AU?

You’ll have to post some more info for the JUCE community to be able to help you with this; these are really broad questions you’re asking. A stack trace or something could help us help you.

Understood, but unfortunately, there is very little info here to go on. Here’s the crash report:

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000129fa5c28
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]

VM Regions Near 0x129fa5c28:
Memory Tag 249 0000000129819000-000000012982c000 [ 76K] rw-/rwx SM=COW

MALLOC_LARGE 000000012aa95000-000000012ab95000 [ 1024K] rw-/rwx SM=PRV

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.presonus.studioone2 0x000000010cbbd84e 0x10c2eb000 + 9250894
1 com.presonus.studioone2 0x000000010cbbd8ee 0x10c2eb000 + 9251054
2 com.presonus.studioone2 0x000000010d04411c 0x10c2eb000 + 13996316
3 com.presonus.studioone2 0x000000010ca51a96 0x10c2eb000 + 7760534
4 com.presonus.studioone2 0x000000010ca4fff6 0x10c2eb000 + 7753718
5 libsystem_c.dylib 0x00007fff64922eed __cxa_finalize_ranges + 351
6 libsystem_c.dylib 0x00007fff649231fe exit + 55
7 libdyld.dylib 0x00007fff6487601c start + 8

When debugging, I see that it succeeds in saving my session (and I can verify the changes when I re-open). Then there are several leaks detected when someting called cxa_finalize_ranges is executed, then the crash somewhere deeper in Studio One’s code. (The leaks don’t happen in other hosts or in VST3, by the way.)

Here is the output in a Terminal window. I don’t recognize any of those objects listed as leaks.

*** Leaked objects detected: 120 instance(s) of class CachedGlyphEdgeTable
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class GlyphCache
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 2 instance(s) of class OSXTypeface
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 2 instance(s) of class Typeface
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 82 instance(s) of class EdgeTable
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 166 instance(s) of class CoreGraphicsImage
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 166 instance(s) of class ImagePixelData
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class OwnedArray
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 120 instance(s) of class Font
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class TypefaceCache
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class LookAndFeel_V4
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class LookAndFeel_V2
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class LookAndFeel
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class DisplaySettingsChangeCallback
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class Desktop
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class MouseInputSource
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class MouseInputSourceInternal
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class OwnedArray
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class ComponentAnimator
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class OwnedArray
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
Segmentation fault: 11

Looks pretty serious. Perhaps you should reach out to Studio One support in this instance. From what I see, there’s not too much advice I can give.

Perhaps don’t create your UI on launch and see if it happens, then bring back your panels / components one by one and test it until it crashes.

My plug-in has no issues like that in Studio One v3 or v4. I’d suggest you add a FileLogger to your code and start logging to see where it’s crashing. I suspect you’re trying to write to an invalid object after it’s destroyed.

Rail

About the leak detector:
The JUCE leak detector can only find classes, that have either JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR or JUCE_LEAK_DETECTOR set.
If you add one of these macros to your class, it will spot them as well and help a lot finding the leak.

If any object is leaking, naturally all it’s members are leaking as well, so you are probably seeing the members of one of your own classes.

TL;DR: first step is to add in the private section of your class:

JUCE_LEAK_DETECTOR (MyClassName)
// or for non copyable (all components)
JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (MyClassName)