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

Reply via email to