On Oct 22, 2008, at 1: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.
Retain counts != memory leaks. If you make sure zombies are turned off
(which they are, by default), and run the code in MallocDebug, and
MallocDebug does not report a leak after the code is run, then the
memory was not leaked. But if it does, and you're sure zombies are
off, then you just might have found a leak in a system framework, and
should probably report it.
It's generally good advice to just ignore retain counts and follow the
memory management rules as written. Also, memory leaks in system
frameworks are quite rare. There were some real leaks in the past
(e.g. the NSCalendar and NSDateFormatter classes were very leaky in
Tiger), but they were fixed a while ago.
Nick Zitzmann
<http://www.chronosnet.com/>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
