On 11/01/2010, at 4:43 AM, Joar Wingfors wrote: >> [pObj release]; // <-- This should assert in a debug context, since it >> is already in the current autorelease pool. > > > There is nothing wrong with releasing objects that have been added to > autorelease pools per se, what could be considered incorrect in this line of > code is the ordering of the memory management method calls. They should > ideally be called and nested in a logical order where the sum of all current > and "future" calls to memory management methods never end up in the negative > (unless I forget some use case where that is needed?). At least in theory it > would probably be possible to assert that this holds true.
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. --Graham _______________________________________________ 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
