AAX Crash on Catalina

I’ve contacted Avid dev services and they are looking into it.
Don’t know yet if this is a Juce or Protools issue.

This looks like memory smashing.
I wonder if this could be related to this code

   # if JUCE_MAC && defined (MAC_OS_X_VERSION_10_14) && MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_14
    // This version of the SDK intermittently requires a bit of extra space
    // at the end of the image data. This feels like something has gone
    // wrong in Apple's code.
    numComponents += (size_t) lineStride;
   #endif

Still I build with 10.12 SDK but it should maybe be a check on the OS and not the base SDK.

It looks like there is a problem with the visibility of the juce::CoreGraphicsImage symbol at the point where the dynamic_cast is traversed. Changing the name of this class resolves the conflict, but unfortunately this workaround requires patching the JUCE library code.

3 Likes

I confirm that renaming CoreGraphicsImage class to MyCoreGraphicsImage did the trick in my case.

unfortunately, it doesn’t resolve the problem in my case
with dynamic_cast, it crashes in juce_mac_NSViewComponentPeer.mm

static void drawRect ( id self , SEL , NSRect r) { if ( auto * p = getOwner ( self )) p->drawRect ( r ); }

with static_cast, it crashes in juce_Component.cpp

bool Component::isOpaque() const noexcept
{
return flags.opaqueFlag;
}

How can I trigger the isOpaque or drawRect crash? I’ve not been able to discover anything more than what’s in this thread from poking around CoreGraphicsImage.

Although, the name change to the CoreGraphicsImage class name does the dynamic cast successfully, and helps fix the issue in my case, I do know another plug-in that does not need this change. It runs fine with JUCE 5.4.2 on Catalina and loads the PNG fine. Still figuring out what the difference in the two plug-ins is. So, it seems like the fix to run on Catalina might be bigger.

Hi Tom,

I just solved the problem.
Previously, I used to compile the Juce library as a static library linked with my projects.
It worked well with all formats, on all MacOS version.
As the problem with CoreGraphicsImage seems to be related to the link, I tried to include all the juce sources in my project, as Projucer does, to no longer link with the static library.
And now it works, I don’t have the problem with isOpaque or drawRect anymore.

But there is still the problem with CoreGraphicsImage.
Maybe this problem is not just about CoreGraphicsImage and is more general…

Best,

Emmanuel

Rob has troubleshooted the thing a little further. Contact him off list and he can probably send you his finding. He probably don’t want to discuss inner Protools thing on a public forum.

isOpaque crash happened in my case when I was using the developer version of Protools with the static_cast thing mods.

After some monkeying around in the internals of Pro Tools I think I’ve worked out what’s going on.

Here’s a patched version of a binary component of the 2019.R2 Development Pro Tools app.

ClipFX.patched.zip (930.4 KB)

If you replace Pro Tools.app/Contents/Frameworks/ClipFX.framework/Versions/A/ClipFX with this version then I believe JUCE-based plug-ins will work as expected.

Keep a copy of the old file around! This patch is pretty brutal and may make other bits of Pro Tools unstable.

1 Like

Yes, the patch seems to solve the CoreGraphicsImage problem

@t0m if the develop commit isn’t really fixing it, might be worth reverting it.

Unfortunately things need to be changed in Pro Tools for a comprehensive fix. Versions 2019.12 and possibly the upcoming 2020 release (if there’s time for the bug fix to get in) will be affected.

In the interim I think there’s some merit in avoiding the crash most widely reported in this thread.

In the interim I think there’s some merit in avoiding the crash most widely reported in this thread.

IIUC if this is a symbol clash, isn’t stripping symbols on release builds would avoid the crash on released products?

It’s a little more complicated than that.

The dynamic cast is failing even though the definition of the cast target is inside the same compilation unit. Changing the visibility of the symbols you are in control of won’t change the outcome.

I don’t want to spill too many details about Pro Tools internals here!

1 Like

c++ isn’t supposed to have a two level namespace ?
While I’m aware of such issue in objC code, I though it wasn’t possible in c++

1 Like

To add some more pepper: I see the CoreCraphics crash in the plugins debug build and PT 2019 R2 1 329 3PDEV, but can’t reproduce this with PT 2020.3.0 and (notarized, AAX signed and PACE wrapped) release builds … Has this been fixed now?

For debugging:

What would that be? Installing the ClipFX.patched.zip?
Crossing my fingers this doesn’t make the PT debug expierence even worse - if that’s possible at all…

Do you see the crash on debug plugins built using the develop branch (rather than master)?

No, we are at release 5.4.5.

Was there a specific commit or commits that you added to JUCE that you believe solved this? I’d like to try cherry-picking them to JUCE 5 as we’re too close to a release to do a major framework upgrade.

Here’s what we added in the framework itself: https://github.com/juce-framework/JUCE/commit/9798f672c48254cadc91f52b89b8e5a148761301