JuceDemoPlugin crashes under Tiger Mac OSX


I’ve just checked the latest tip from GIT and noticed that JuceDemoPlugin crashes Live 8.0.5 (VST and AU), GarageBand, Logic 8 on Mac OSX 10.4.11 (Tiger). The crash happens when JuceDemoPlugin is simply inserted.

Here is crash log from Garage Band:


Host Name:      ##########
Date/Time:      2009-11-09 17:54:05.189 +0100
OS Version:     10.4.11 (Build 8S2167)
Report Version: 4

Command: GarageBand
Path:    /Applications/GarageBand.app/Contents/MacOS/GarageBand
Parent:  WindowServer [55]

Version:        3.0.0 (72)
Build Version:  14
Project Name:   GarageBand
Source Version: 1140000

PID:    257
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x63754a5f

Thread 0 Crashed:
0   libobjc.A.dylib                	0x90a5b0d0 class_respondsToMethod + 120
1   com.apple.Foundation           	0x9280e3e4 -[NSBundle load] + 766
2   com.apple.Foundation           	0x92872e12 -[NSBundle classNamed:] + 41
3   com.apple.garageband           	0x0004155d 0x1000 + 263517
4   com.apple.garageband           	0x000401a6 0x1000 + 258470
5   com.apple.garageband           	0x00051e58 0x1000 + 331352
6   com.apple.AppKit               	0x9336c7cc -[NSApplication sendAction:to:from:] + 107
7   com.apple.ecore                	0x0182bf6d -[EcButtonCell sendAction] + 487
8   com.apple.ecore                	0x0182b896 -[EcButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 752
9   com.apple.AppKit               	0x9339e549 -[NSControl mouseDown:] + 757
10  com.apple.AppKit               	0x9335bdf3 -[NSWindow sendEvent:] + 5279
11  com.apple.AppKit               	0x9334dd8c -[NSApplication sendEvent:] + 5023
12  com.apple.garageband           	0x00070296 0x1000 + 455318
13  com.apple.AppKit               	0x932788e7 -[NSApplication run] + 547
14  com.apple.AppKit               	0x9326c820 NSApplicationMain + 573
15  com.apple.garageband           	0x001772d8 0x1000 + 1532632
16  com.apple.garageband           	0x000029ce 0x1000 + 6606
17  com.apple.garageband           	0x000028e9 0x1000 + 6377

Thread 1:
0   libSystem.B.dylib              	0x9003f21f syscall_thread_switch + 7
1   com.apple.AppKit               	0x933560b2 -[NSUIHeartBeat _heartBeatThread:] + 1399
2   com.apple.Foundation           	0x927f9cfc forkThreadForFunction + 123
3   libSystem.B.dylib              	0x90023d67 _pthread_body + 84


Did you actually link it with the 10.4 SDK? If you use a later SDK, it could easily crash on an older OS.


Yes, I set the Mac OS X Deployment Target to 10.4.

I forgot to tell that demo plugin passes auval test correct, it crashes only when inserted to host app.


That’s strange then - the stack trace seems to show it crashing before the module is even loaded.


I’ll dig it deeper…

Did you think about adding ready to use JuceDemoPlugin version to the extras/prebuilt directory? In such way we could test it easier during juce updates and without harming the procedure by our builds.


I found something strange. I’ve tested the juce demo app on these Tiger OSX I wrote before. The prebuilt version from tip works correct, but when I build my version of juce demo it crashes on Tiger.

I build on 10.6.1 with XCode 3.2. I see that Base SDK for Juce Demo project is set to Current Mac OS value and Deployment Target is set to Mac OS X 10.4 so if I understand it, it should works on 10.4 and higher OS X. Am I right?

On the 10.6.1 used to build it works smoothly however it crashes on 10.4.11. Here is portion from crash log…

Thread 0 Crashed:
0   <<00000000>> 	0x00000000 0 + 0
1   ...awmaterialsoftware.jucedemo 	0x00141c3a juce::Typeface::createSystemTypefaceFor(juce::Font const&) + 52
2   ...awmaterialsoftware.jucedemo 	0x00141db4 juce::LookAndFeel::getTypefaceForFont(juce::Font const&) + 316
3   ...awmaterialsoftware.jucedemo 	0x0022bc99 juce::TypefaceCache::findTypefaceFor(juce::Font const&) + 453
4   ...awmaterialsoftware.jucedemo 	0x00199ec7 juce::Font::getTypeface() const + 73
5   ...awmaterialsoftware.jucedemo 	0x0019b230 juce::Font::getStringWidthFloat(juce::String const&) const + 30
6   ...awmaterialsoftware.jucedemo 	0x0019b32a juce::Font::getStringWidth(juce::String const&) const + 30
7   ...awmaterialsoftware.jucedemo 	0x0019b826 juce::LookAndFeel::getMenuBarItemWidth(juce::MenuBarComponent&, int, juce::String const&) + 82
8   ...awmaterialsoftware.jucedemo 	0x0014acc8 juce::MenuBarComponent::resized() + 136
9   ...awmaterialsoftware.jucedemo 	0x00166692 juce::MenuBarComponent::menuBarItemsChanged(juce::MenuBarModel*) + 174
10  ...awmaterialsoftware.jucedemo 	0x00186c7d juce::MenuBarComponent::setModel(juce::MenuBarModel*) + 139
11  ...awmaterialsoftware.jucedemo 	0x001e15ac juce::MenuBarComponent::MenuBarComponent[in-charge](juce::MenuBarModel*) + 346
12  ...awmaterialsoftware.jucedemo 	0x001e16f9 juce::DocumentWindow::setMenuBar(juce::MenuBarModel*, int) + 207
13  ...awmaterialsoftware.jucedemo 	0x0027f2c6 MainDemoWindow::MainDemoWindow[in-charge]() + 562
14  ...awmaterialsoftware.jucedemo 	0x00021e9b JUCEDemoApplication::initialise(juce::String const&) + 39
15  ...awmaterialsoftware.jucedemo 	0x001c538e juce::JUCEApplication::initialiseApp(juce::String&) + 474
16  ...awmaterialsoftware.jucedemo 	0x001c5552 juce::JUCEApplication::main(juce::String&, juce::JUCEApplication*) + 38
17  ...awmaterialsoftware.jucedemo 	0x001c5745 juce::JUCEApplication::main(int, char**, juce::JUCEApplication*) + 157
18  ...awmaterialsoftware.jucedemo 	0x000214df main + 97
19  ...awmaterialsoftware.jucedemo 	0x0000637d _start + 208
20  ...awmaterialsoftware.jucedemo 	0x000062ac start + 40

Can it be some bug near the last changes with Typeface and Font classes?
What is the XCode and OSX versions which prebuilt versions are built on?

Maybe we should we update some SDK or something on our machines to deal properly with the laste changes in juce?



I’m downloading the updates to 10.6.2 OSX and XCode 3.2.1… we’ll see


Unfortunately with the latest OSX 10.6.2 and XCode 3.2.1 the problem still exists.


I’ve been doing a lot of checking-in in the last few days - maybe try the tip again now?


I have the latest tip (2009-11-10, 01:31:53)


Well it’s all working fine here for me here in 10.6.1. You’re sure you did a full rebuild?

It makes no sense that it would crash in that function anyway. Can you give me any more info from debugging it?


Yes, I did full rebuild, cleaning all the targets before

I’m not sure If I made my correct. My build is working on my 10.6.2 (and previously on 10.6.1) but not on 10.4.11.

Your build (from extras/prebuilt) is working on both OSX versions.

That’s why I’m wondering if your configuration (on which prebuilts are made) isn’t specific in some point?

debug … hmmmm … how can I debug it on this 10.4.11 when I don’t have XCode installed on it? I always used to run the build-in debugger from XCode. Any hints how to debug it without XCode?


Really sorry for such a dumb problem but I started to wonder If I get all the builds details correct.

As far as I know when the active SDK is set to 10.6 and Deployment target is set to 10.4 the code could be run on 10.4 and later. Am I right?

I also tried to set active SDK to 10.4 and then I can’t compile it because I get some errors in MacTypeface class. It can’t find the CGFontCreateWithFontName() method. Following the Mac OSX Reference Library this method is available on 10.5 and higher.

So I have no idea how the prebuilt version is compiled than I can run it on 10.4.11 without any problems.


That’s the theory. But presumably if 10.4 is missing that CGFontCreateWithFontName call, it might be crashing when trying to call it. I’ll see if I can add a fallback to open the font with an older function on 10.4, and that might sort it out.


OK, now I know the most strange in this issue. I wondered why my build doesn’t work on 10.4.11 while the prebuilt version does. The answer is that prebuilt version of jucedemo.dmg was built on 2009-09-19 - much before changes in Typeface :slight_smile:

So I guess that if you’d build it this time it won’t run on Tiger OSX. Probably it’s because of the CGFontCreateWithFontName() method. It needs 10.5 as they say in reference library.



… the same with CGFontGetAscent(), CGFontGetUnitsPerEm(), CGFontGetGlyphAdvances(), CGFontCopyTableForTag() etc.

All of they are available in Mac OS X v10.5 and later. So I guess we need some bypass to run in older 10.4 OSX.


Ok, I think that if you replace the CGFontCreateWithFontName call with this:

#if MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_5 if (CGFontCreateWithFontName == 0) { ATSFontRef atsFont = ATSFontFindFromName ((CFStringRef) [nsFont fontName], kATSOptionFlagsDefault); fontRef = CGFontCreateWithPlatformFont ((void*) &atsFont); } else #endif { fontRef = CGFontCreateWithFontName ((CFStringRef) [nsFont fontName]); } #endif

…then if should probably work.


[quote]… the same with CGFontGetAscent(), CGFontGetUnitsPerEm(), CGFontGetGlyphAdvances(), CGFontCopyTableForTag() etc.

All of they are available in Mac OS X v10.5 and later. So I guess we need some bypass to run in older 10.4 OSX.[/quote]

…ah… Those are a bit more tricky to replace…


When you set the active SDK to 10.4 with the combo box in upper-left corner in XCode and compile you’ll see all 13 errors caused by code not available in OSX 10.4.x


XCode has magically removed the 10.4 SDK from my machine, so that’s not possible.

Am extremely pissed off about this - that font class was looking great, and now I have to spend ages messing it all up again to deal with all this 10.4 crap…