Re: [NSCalendar currentCalendar] leak
Re: [NSCalendar currentCalendar] leak
- Subject: Re: [NSCalendar currentCalendar] leak
- From: Mike Abdullah <email@hidden>
- Date: Tue, 7 Nov 2006 08:46:02 +0000
Thanks very much for the feedback guys. I think Daniel's probably
right and that I should really be using CFCalendarCopyCurrent() in my
implementation.
Additionally, I think he's correct and that I should avoid using a
category to override this method. Instead, I shall just create a
different method -nonLeakyCurrentCalendar and call that in my code.
I shall also look into OBReplaceMethod, I hadn't previously
considered swizzling.
Mike.
On 5 Nov 2006, at 19:17, Adam R. Maxwell wrote:
On Nov 5, 2006, at 08:01, Daniel Jalkut wrote:
On Nov 5, 2006, at 8:50 AM, Mike Abdullah wrote:
Again, not a problem. If the framework changes, my
implementation will still be used.
Which begs the question, what use is it for you to override
"currentCalendar" at all?
It would keep underlying code in the frameworks that uses
+currentCalendar from leaking (not to speak for Mike...that would
be my reason for it).
This technique of using a category to "override" seems very
fragile to me. I can't imagine there is a guarantee that yours
will override the original, except that by luck it happens to be
loaded dynamically later than the original.
I believe the category is loaded after the class, so this will work
unless Apple puts +currentCalendar in a category; in that case,
it's undefined which one will win out. It's likely that this won't
happen on 10.4, at least, but using something like Omni's
OBReplaceMethod... functions may be more reliable, and you can
decide at runtime whether to replace the method or not.
[...]
At the very least we might at least examine what's going on in the
method, to reassure ourselves.
bl 0x92adb880 <dyld_stub_CFCalendarCopyCurrent>
bl 0x92ad49a0 <dyld_stub_CFMakeCollectable>
lwz r0,88(r1)
addis r4,r31,4076
addi r1,r1,80
lwz r4,-15100(r4)
mtlr r0
lmw r30,-8(r1)
ba 0xfffeff00 <objc_msgSend_rtp>
By looking at what "currentCalendar" actually does, we not only
get a great idea of how we can best imitate it, we also see
exactly what's causing the bug. Oops! Apple is using garbage
collection to manage the memory for this object. Apparently
somebody didn't get the memo that this wasn't going in for 10.4.
I've seen various garbage collection calls in my code when running
under Shark, and it doesn't leak. My guess was that this is
available to CF, but I could be wrong on that.
Adam
_______________________________________________
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