I think this is a great idea! I personally find the fact that autorelease pools are totally opaque extremely unhelpful. Have you got the energy to file an enhancement request Graham? I'd like to see a method to dump out all the objects in the current chain of autoreleasepools, too.
I did read your comments joar. My own view is that just about everybody has a niggly memory-management bug at some point and the more help there is available when that happens the better. It would be extremely simple for Apple to implement this suggestion and there's no question in my mind that it would rapidly nail a certain class of bug, so what's to lose? I took a quick peek inside NSAutoreleasePool's iVar's to see if we can roll our own, but no obvious help there. I don't care if any viable scheme is supported or not. It's only for debugging. On a more philosophical note, I think the current situation for many people is that they are scared of over-releasing things. Result: memory leaks, so anything that can be done to take some of the fear away can only be a good thing. Of course, GC will fix everything... Paul Sanders. ----- Original Message ----- From: "Graham Cox" <graham....@bigpond.com> To: "Joar Wingfors" <j...@joar.com> Cc: "Cocoa Dev" <cocoa-dev@lists.apple.com> Sent: Sunday, January 10, 2010 11:26 PM Subject: Re: if statement causing 32 Byte leak? I think what would be useful is a debugging method that can check at dealloc time whether the object is also referenced within an autorelease pool. One of the hardest over-release bugs to find is when an autorelease pool pops and the object has already gone - it might be a long way past where the real problem is. Zombies definitely helps with this, but you still need a lot of detective work. If at dealloc time you could assert on a *future* autorelease crash, that would stop the program at the real point of failure. If there were any way to walk the autorelease pools we could write our own, but there doesn't seem to be a supported way to do it. _______________________________________________ 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 arch...@mail-archive.com
