Re: [NSCalendar currentCalendar] leak
Re: [NSCalendar currentCalendar] leak
- Subject: Re: [NSCalendar currentCalendar] leak
- From: Mike Abdullah <email@hidden>
- Date: Sun, 5 Nov 2006 13:50:28 +0000
On 4 Nov 2006, at 15:16, Matt Neuburg wrote:
On Fri, 3 Nov 2006 19:11:13 +0000, Mike Abdullah
<email@hidden>
said:
Just for the archives, I implemented this category to fix the
problem:
@implementation NSCalendar (RealCurrentCalendar)
// We are overriding the default implementation of currentCalendar
since it leaks like a sieve.
+ (id)currentCalendar
{
NSString *localeIdentifier = [[NSLocale currentLocale] objectForKey:
NSLocaleCalendar];
NSCalendar *currentCalendar =
[[[NSCalendar alloc] initWithCalendarIdentifier: localeIdentifier]
autorelease];
return currentCalendar;
}
@end
That sort of trick works if you know for an absolute fact what the
framework
is doing "wrong" and that it does it with perfect consistency, but
here are
two warnings: (1) You don't know this (how, for example, do you
know for a
fact that there might not be some cases where the framework does NOT
over-retain the calendar?)
But that's not an issue here since I'm completely overriding the -
currentCalendar method. The framework no longer gets a chance to
over-retain anything.
, and (2) behaviour might change in the future
(since this over-retaining is obviously a bug). Thus you are risking a
mysterious crash.
Again, not a problem. If the framework changes, my implementation
will still be used.
I find it better practice not to try to second-guess
leak-causing behavior by the framework. In reality, I would
conjecture, you
are probably not generating enough calendars for the leak to matter
to your
users; you yourself know about it only because you've been spending
too much
time hunched over ObjectAlloc. :)
In my app I call and use -currentCalendar rather a lot! My app
performs a lot of conversion between NSDate and NSDateComponents and
the leak was pretty obvious using the leaks command line tool.
In fact, not only does an instance of NSCalendar get leaked, but so
does an NSLocale and other object (can't remember what off the top of
my head!). So, whilst it doesn't have a huge impact on memory, it
does make future use of the leaks tool rather awkward since the list
is cluttered up with many instances like this.
I say all this because that is how I "fixed" the leak I've just
discovered
in my AppleScript Studio hybrid Obj-C / AppleScript application.
This is the
framework's bug: two extra retains are added to a non-bridged
object when
"call method" receives it as it's result. I thought about and tried
various
ways of defeating the leak, but then I did some real-world
measurements and
decided that, in practice, no one would notice the leak unless they
had
fifty monkeys hammering away at the app for a month on end. So my
"fix" was
to walk away and stop worrying. m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden