Autorelease pools and fonts


Hi All,
I have a question. It is with reference to this link.

Crash in Font Class on Snow Leopard

As I had said in the thread, I had moved Font code from juce 1.50 to juce 1.39 to fix it. But I didn’t move the ScopedAutoReleasePool code, because I thought it was not needed.

Yesterday I had to face a issue, if I tried load displaying all the glyphs in the font on my application it used to take 4-5 mins, hanging in mac frameworks.

But after I moved ScopedAutoReleasePool to my cocktail version of juce. The Hang reduced dramatically to 4 seconds.

Any specific reason for this behaviour? :?:


Without the AutoreleasePool you were probably leaking objects like crazy and then started paging out. In the console it probably would have spat out a bunch of No AutoreleasePool messages in place.

There are a only a few “autoreleased” objects in the font class.
ie. [NSFontManager sharedFontManager]
[NSMutableDictionary dictionaryWithObject]
[NSBezierPath bezierPath]

but when you are iterating over a few fonts with lots of glyphs, that adds up fast!

Hope that helps



It did and helped me crack the hang :slight_smile: . But it sounds odd that leaks involving 155 characters can cause my application to hang!!!:shock:

You could be right here, because the delay is only for the first load after that it runs smoothly.


The Instruments app is awesome(objectalloc I think?) for this kind of stuff. Set it to still living objects, and sort by net. If that number is climbing and climbing and not going down, you are leaking! I think you can even set it to watch just Appkit/Cocoa objects.

The graph is fun to watch too! All that memory getting gobbled up, we’re such pigs these days.


Oh one more tip…I haven’t tried it, but just read about it the other day. In Spin Control(also in Performance tools), you can set it to watch for a spin lock. So when your app hangs it starts sampling and then you can track down what it was doing.

I think there’s an option in Shark as well. If I find it i’ll post it here.


It never occurred to me that it had something to do with memory leaks, I tried profiling it using shark but to no avail. Shark hanged :shock:. It’s a good tip though.


In a pinch i’ve used Activity Monitor in /Applications/Utilities, double click your app name and then you can sample from there.


This is by far the simplest to use.


Just an extra input, xcode on leopard and snow leopard has a performance tool called Leaks( for detecting memory leaks), I found it the most simplest of the application to use.

Just go to run menu ->Run with Performace Tools -> Leaks.