Bug: MacOS Fonts causing other GUIs to crash

Audio Plugins
1

We’ve had several reports recently that our plug-ins have been causing iZotope’s plug-ins to crash when their GUIs are opened (somewhere below [NSView _setWindow:], according to the crash log).

This seems to be caused by us loading fonts from memory, and removing the call to CTFontManagerRegisterGraphicsFont here is the only way to resolve the crash.

Looking at the code there, I believe it’s only recently become an issue as we have increased our minimum supported MacOS version to 10.8, which has triggered these calls to begin in new builds.

Is there any chance this could be a JUCE bug, or is it more likely to be an OSX bug?

1 Like
2

The line you suggest removing appears to be relatively new (2 years). Did you try to bisect and see if it used to be fine and the problem was caused by recent changes?

1 Like
3

From what I’ve seen so far this has been an issue since the code was reformatted to support the MacOS font manager (as you say, about two years ago). As I mentioned above, it’s only started to manifest now because we’ve updated our minimum OS requirement to 10.8, which satisfies the pre-processor definition wrapping up the code in question.

I’m starting to suspect there may be something simple going on like we’re registering the same fonts (Source Sans Pro is the one causing an issue, but I have yet to test with other fonts we have available) and MacOS doesn’t like it. Because Apple. There could also be a clash with the SDK we’re compiling against. We are using 10.15 SDK, iZotope are using 10.13 SDK.

So there are a few other things with this specific case I can investigate, but I was rather hoping this was something the guys at JUCE would know more about than me and would have a better idea about what could be going wrong.

4

Sure, but if possible I’d recommend going the extra mile when reporting bugs, it will increase your chances on getting the fix sooner and will help point the JUCE team in the right direction.

1 Like
5

I’ve been struggling with font crashes for a few years as well, I think there are a few other threads about it like: Occasional glyph crash and Typeface::createSystemTypefaceFor Leaks on Mac

The issue I see is that glyphs start randomly disappearing / getting scrambled and then shortly after the program crashes. Only caused by using memory font on macOS.

I’ve spent a decent amount of time looking into it, never been able to find the cause.

3 Likes
6

I’ve quickly put together a test repository which demonstrates this crash:

2 Likes
7

Hi, any news on this? We’re experiencing the same issue on JUCE 5.4 (our plugins make iZotope’s GUI crash on display).

8

Checkout the demo repo I’ve linked above, the PluginEditor.cpp file has some information about how we worked around the problem.

9

This might not be the cause of the issues, but here’s a guess anyway: If you are loading your font from memory, maybe the version you register with the font manager is clashing with fonts of the same name/ids used by other plugins.
I used FontForge to rename/re-id the fonts I use before I embed them in my binaries.

2 Likes
10

I think you’re exactly right, which is why removing JUCE’s use CTFontManagerRegisterGraphicsFont fixes the issue. I think that system is most likely trying to reuse fonts when there are ID clashes (well, matches, which is the opposite of clashes), and something about them being in the static memory space of a different plug-in is what’s causing the iZotope plug-ins to crash because they can’t properly access that memory.

At least that’s what I can gather from the time I’ve spent investigating. So our solution was to simply stop the fonts we were loading from being stored in static variables.

1 Like
12

Hi all, thanks for your answers. I can confirm the findings above and solved the problem myself by renaming the font.

2 Likes