[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Notifications sent in -(void)dealloc
From: |
Richard Frith-Macdonald |
Subject: |
Re: Notifications sent in -(void)dealloc |
Date: |
Wed, 7 Aug 2002 14:49:39 +0100 |
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.
- Re: Notifications sent in -(void)dealloc,
Richard Frith-Macdonald <=