Re: RFA: NSAutoreleasePool ivar cleanup

[Richard Frith-Macdonald]

On 24 Mar 2011, at 06:00, David Ayers wrote:

> Hi folks,
> 
> I was chasing a sporadic (very seldom) crash which we noticed on
> production instances.  The version of the libraries we are using is
> ancient.  But the issue may still exist.
> 
> in NSAutoreleasePool -emptyPool there is this comment:
>      /* If there are NSAutoreleasePool below us in the stack of
>         NSAutoreleasePools, then deallocate them also.  The (only) way
> we
>         could get in this situation (in correctly written programs,
> that
>         don't release NSAutoreleasePools in weird ways), is if an
>         exception threw us up the stack. */
>      while (_child != nil)
>        {
>          [_child dealloc];
>        }
> 
> well... we may have an incorrectly written program here and we may not
> catch alle exceptions properly but I currently cannot tell for sure.
> But whether correct or not, I believe the _child ivar should be cleared
> after the dealloc since release pools get recycled.

If you look at the implementation of -dealloc, you will see that in it the 
child removes itsself from its parent (by clearing parent->_child).
You can be sure that _child is set to nil ... if it didn't, the while loop 
would never terminate.
Your patch, setting _child to nil after deallocating it, ought to have no 
effect (other than wasting a tiny amount of cpu time) unless you have some 
problem elsewhere which is corrupting the _child ivar during the call to 
dealloc (after the point where it is set to nil).  As far as I can see the only 
thing going on there is pushing the deallocated pool to the cache ... perhaps a 
problem in the cache?  More likely I would have thought, would be memory 
corruption caused by another thread.