Re: Memory Leaks in CocoaEcho Sample
Re: Memory Leaks in CocoaEcho Sample
- Subject: Re: Memory Leaks in CocoaEcho Sample
- From: Bill Bumgarner <email@hidden>
- Date: Wed, 22 Oct 2008 13:04:35 -0700
On Oct 22, 2008, at 12:54 PM, Marco Masser wrote:
I don't know of any way to look into an autorelease pool, if you
mean that : )
I just made an NSColor ivar and retained it after calling -
getColor:location:atIndex: and took a look on its retain count in a
second method that was called after the NSAutoreleasePool had been
drained (i.e. I took a look at the retain count after pressing a
button). That way, all -autorelease messages must have been dealt
with. In the second method, the count was 2. After removing the -
retain following the -getColor..., the retain count in the second
method was 1.
In general, the retain count is entirely meaningless. The retain
count of any given object, especially objects that were created by or
have passed through the Apple provided frameworks, may be seemingly
random due to the internal implementation details of the class or of
the frameworks. Caching, singletons, and any of a number of
optimizations could impact the retain count.
Frankly, -retainCount should be deprecated and eliminated.
If you are trying to find a leak, then use one of the tools on the
system designed for exactly that -- leaks, Object Graph in Instruments
for GC, Object Alloc for non-GC, etc...
Now... in this particular case...
How can you look at the retain count of an object after the
autorelease pool was drained without it being retained by something?
Didn't you have to retain it to keep the NSColor iVar around?
b.bum
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden