Leopard and Tiger Notification Differences?

FROM : John Nairn
DATE : Fri Feb 08 22:58:00 2008

I have run into several crashes in Leopard that never happened in 
Tiger. In all cases, the problem has been a notification sent to a 
deallocated object. I have been able to fix them, but why do these 
bugs keep happening in Leopard. Either Tiger was smarter (i.e., not 
sending messages to deallocated objects) or Leopard is handling 
notifications differently. I can document a difference now and wonder 
how is one supposed to know what to expect?

These two lines respond to a menu command to delete a record of data 
being displayed in the main window

   [[self document] performSelector:@selector(deleteRecordHere:) 
withObject:theRecord afterDelay:0.0];
   [self close];

The first line schedules a call to the document to delete the record's 
data. The close line closes the window and its controller. In Tiger, 
this works fine, but in Leopard in crashes, and tasks in the two 
systems happen in a different order. In Tiger:

1. The close causes the window controller to dealloc
2. Along with the window controller, all the interface objects from 
the nib file get deallocated
3. Finally, the deleteRecordHere: is invoked to remove data from the 
document.

The exact same code in Leopard happens in a different order

1. The close causes the window controller to dealloc, but not the 
interface objects
2. The deleteRecordHere: method is invoked
3. Finally, after a delay, the interface objects are released.

Now many times this order may not be important, but my particular 
application sends notifications while deleting the record that may 
happen to go to interface objects and those objects use methods in the 
window controller that owns them. Because the window controller was 
released, these notifications cause a message to a deallocated object 
and a crash.

I solved the Leopard crash by moving my [self close] to another 
notification that gets calls when the record deleting is done in the 
document, but why would leopard split up the deallocation of a window 
and its objects into two sections and intersperse other scheduled 
methods in the middle? Is there a better way to get a selector called 
at a more convenient time? I want my delete record selector called 
only after the window and its objects are deallocated.

---------------
John Nairn (1-541-737-4265, FAX:1-541-737-3385)
Professor and Richardson Chair
Web Page: http://woodscience.oregonstate.edu/faculty/Nairn
FEA/MPM Web Page: http://oregonstate.edu/~nairnj