Thanks to Hamish and Kai for their suggestions - the help is much
appreciated. For now, I'm just being careful to autorelease where
there is a potential problem, as Kai suggested. (Though I suspect
that, in general, it's equivalent to the halting problem to determine
which instances of release must be replaced with autorelease to avoid
the problem, it's clear enough in my application :))
Submitted to bugreport.apple.com as #5976416.
Geoff
On May 30, 2008, at 2:07 AM, Kai wrote:
On 30.5.2008, at 00:53, Hamish Allan wrote:
On Thu, May 29, 2008 at 11:15 PM, Geoff Schmidt
<email@hidden> wrote:
3) If this is already known, is there a customary pattern for
avoiding the
problem? "Never release from observeValueForKeyPath" is a bit harsh!
I don't know if it's known, but you could try [obj
performSelector:@selector(release) withObject:nil afterDelay:0]
instead of [obj release]
Or use [obj autorelease] instead of [obj release] which should be
pretty much the same with less typing. Again, you probably need to
be able to handle the extra observeValueForKeyPath:
(My guess is that when A receives observeValueForKeyPath:, it is
already too late to still remove B from the list of objects which
will be notified. Most likely some kind of copy is made of the list
of objects to notify internally by Cocoa.)
Kai
if you don't mind getting the extraneous
observeValueForKeyPath:... for that obj (it could have an "about
to be
released" flag which would cause it to ignore the
observeValueForKeyPath:...)
