Re: Notifications sent in -(void)dealloc

[Richard Frith-Macdonald]

On Wednesday, July 17, 2002, at 06:56 PM, Adam Fedor wrote:

> Marcus Müller wrote:
> > Hi,
> > I just stumbled across some interesting problem. If you post a 
> > notification in one object's dealloc and send 'self' as the object of 
> > the notification, it later on crashes during an AutoreleasePool's 
> > release method (although the object gets retained by the notification, 
> > so its deallocation should be cancelled). It doesn't crash on Mac OS 
> > X, however.
> > A testcase for this problem (GNUstep and OS X project) can be found at
> > http://www.mulle-kybernetik.com/~znek/GNUstep/Notifications.tar.bz2
>
>
> Funny. Richard fixed this, or at least it says that he fixed this in 
> the ChangeLog (Jun 2 2002). But it doesn't appear the code was actually 
> changed. Bummer that he's out of town now...

It *was* modified to behave the same way as the MacOS-X implementation 
(slightly different from
what the MacOS-X documentation says) and documented.

The problem here is not with the retain/release/dealloc in NSObject, 
rather it is that the implementations
of NSNotificationCenter differ slightly (though I've now rewritten the 
GNUstep stuff to be like the
MacOS-X stuff).

The order of execution went like this -

release called with retain count 0
 => dealloc called (retain count 0)
  => post notification method entered
   => creation of autoreleased notification instance called
      retain object (count now 1)
   <= creation of autoreleased notification instance completed
   => post notification instance to observers
  <= post notification method completed
  deallocation of original object completed
...
  autorelease pool destroyed
  => notification instance destroyed
   => attempt to release object already deallocated


The new version of NSNotificationCenter no longer uses the standard 
method to
create the notification instance (which returns an autoreleased 
instance), but
employs a private subclass of NSNotification instead.  This gives it the 
ability
to manage allocation/deallocation directly itsself ... so it can avoid 
this
particular problem.


However ... this is not really a gnustep bug ... rather it's highlighting
the fact that it's generally bad to do anything in a dealloc method 
which could
conceivably cause the object being deallocated to be retained and 
released later -
so good practice (where you *must* pass the object being deallocated to 
other methods)
is to at least create/destroy an autorelease pool around those methods - 
that doesn't
eliminate all possible problems, but it deals with most.