AAX Crash on Catalina

An AAX plugin with Image from BinaryData crashes when opened with ProTools on Catalina
It is very easy to reproduce

  • take AudioPluginDemo
  • add an image in projucer (in my case icon.png)
  • load it with getFromMemory
  • backgroundImage = ImageCache::getFromMemory (BinaryData::icon_png, BinaryData::icon_pngSize);

ProTools crashes
Thread 0 Crashed:: Main Thread Dispatch queue: com.apple.main-thread 0 com.JUCE.AudioPluginDemo 0x000000012f60fe27 juce::juce_loadWithCoreImage(juce::InputStream&) + 1063 (juce_mac_CoreGraphicsContext.mm:893) 1 com.JUCE.AudioPluginDemo 0x000000012f658e60 juce::PNGImageFormat::decodeImage(juce::InputStream&) + 32 (juce_PNGLoader.cpp:557) 2 com.JUCE.AudioPluginDemo 0x000000012f60f7b7 juce::ImageFileFormat::loadFrom(juce::InputStream&) + 71 (juce_ImageFileFormat.cpp:83) 3 com.JUCE.AudioPluginDemo 0x000000012f60e23b juce::ImageFileFormat::loadFrom(void const*, unsigned long) + 91 (juce_ImageFileFormat.cpp:106) 4 com.JUCE.AudioPluginDemo 0x000000012f60e156 juce::ImageCache::getFromMemory(void const*, int) + 86 (juce_ImageCache.cpp:152) 5 com.JUCE.AudioPluginDemo 0x000000012f2ea976 JuceDemoPluginAudioProcessor::JuceDemoPluginAudioProcessorEditor::JuceDemoPluginAudioProcessorEditor(JuceDemoPluginAudioProcessor&) + 2262 (AudioPluginDemo.h:378)

The strange thing is that the same code works well in VST and Audio Unit and the same AAX plugin works on the pre-Catalina versions.
Juce 5.4.5
ProTools 2019.11 dev version
ProTools 2019.12 also crash
MacOS 10.15.1

I am looking into a similar problem with my Plugins. At the moment it has been reported that the issue is when using the vst3 version. However, I believe it is due to notarisation which is now a requirement for any software that runs on Catalina - there is a useful post here with some scripts that can be used to perform the notarisation Apple Gatekeeper notarised distributables

Hi Mogwai,
I’m not sure it has to do with the notarization.
I became aware of this bug after using a successfully notarized installer.
I also tried to notarize the AAX plugin itself. ProTools still crashes in ImageCache::getFromMemory

I’m facing the exact same issue here!
The same plugin works well on macOS 10.14 in Pro Tools 2019.6 Dev and 2018.7 Dev.

Interestingly, another plugin I didn’t rebuild yet on 10.15 (no notarization, hardened runtime etc) doesn’t crash so there must be a connection somewhere but I don’t know why yet.

I’ll try to reach out to Avid to see if they have any insight on the issue.

If this crashes in PT Dev, have you attached a debugger to see if you get any clues?

It doesn’t crash in the older dev versions (running on macOS other than Catalina).
There’s no PT Dev version supported on Catalina yet. That makes the issue hard to pin down further…

Yes, the plugin crash when trying to load the image in juce_loadWithCoreImage

Image image (NativeImageType().create (Image::ARGB, // (CoreImage doesn’t work with 24-bit images)
(int) CGImageGetWidth (loadedImage), (int) CGImageGetHeight (loadedImage),
auto cgImage = dynamic_cast<CoreGraphicsImage*> (image.getPixelData());
jassert (cgImage != nullptr); Main Thread (1): EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)

cgImage is a nullptr

I’m using PT 2019.11 Dev which is not fully validated for Catalina, but AudioPluginDemo works if there is no call to ImageCache::getFromMemory

There is a debuggable dev version that works with Catalina, you’ll find it in your Avid account (to be fair it isn’t immediately obvious which one it is, but it’s there so check it out).

I’m not finding I can reproduce any problems loading from an image cache in AAX on Catalina (I have in-service plug-ins that do this and know some customers are using Catalina, and I’ve checked myself as well).

Have you tried a range of images written with different image processing tools? Or you could try swapping out to a jpg perhaps (unless you need transparency)?

I am facing the same issue here. I have tried swapping out the PNGs with SVGs and the plug-in loads fine. And, yes there is a dev version of Pro Tools available, it’s PT 2019.11.

I think there is something happening at this line where we downcast the ImagePixelData to CoreGraphicsImage in the function juce_loadWithCoreImage.

CoreGraphicsImage* **const** cgImage = **dynamic_cast** <CoreGraphicsImage*> (image.getPixelData());

I get a NULL in cgImage, suggesting that the conversion failed for some reason. I don’t see this happening when I am debugging it in an IDE (Xcode) but only when the plug-in is run inside Pro Tools. Could someone fathom why that would be?

1 Like

Having a crash with notarized AAX on catalina here as well. Previous non notarized version worked fine.
Haven’t tried to debug it yet as well

I now found the PT 2019.11 Dev version as well.
It is labelled “2019.R2” in case anyone else is looking for it, too.

Changing the dynamic_cast to a static_cast fixes the crash and my plugin loads again.
It is however not clear to me why the dynamic cast was necessary and why it failed.

I’ll use this as a workaround for now but would like to know why it’s failing and if it’s safe to circumvent this cast (probably not as it was there for a reason I guess).

1 Like

What are you notarising? An installer?

The DMG containing the pkg installer

I’m quite curious since that cannot touch the binary itself how this could make any difference.

Yep. Maybe just a matter of Juce update in the meantime

I confirm that switching from dynamic_cast to static_cast in juce_loadWithCoreImage fixes the issue.

Yes, it fixed the issue for AudioPluginDemo.
but my plugins still crash when opening the window.

juce::Component::isOpaque() const + 12 (juce_Component.cpp:764)
juce::JuceNSViewClass::isOpaque(objc_object*, objc_selector*) + 65 (juce_mac_NSViewComponentPeer.mm:1693)

Any idea from the Juce team ?

Thanks !

I confirm that switching from dynamic_cast to static_cast in juce_mac_CoreGraphicsContext.mm only fixes part of the problem and I still got some crashes in other part of the code

I’m building against 10.12 SDK with Xcode 11.3 on 10.15.2 with latest Juce develop branch

Changing the dynamic_cast to a static_cast does get past the point of crash, but doesn’t solve the issue. I confirm I too see the crash pushed ahead to a certain isOpaque check for a component of the plug-in.

Another workaround to try is forcing JUCE to pick another image decoding library instead of CoreGraphics. We tried to unset the JUCE_USE_COREIMAGE_LOADER in AppConfig.h to do that. Just a word of caution, there is also a JUCE_USING_COREIMAGE_LOADER which is an integer 0/1 based on if JUCE_USE_COREIMAGE_LOADER is defined or not. So with PNG helper the image loads fine and no crash. But, we did not have to do it until Catalina released. So, that’s still mystery as to why decoding with CoreGraphics framework worked up until Mojave. Any thoughts or ideas would be much appreciated!