Leopard and Tiger Notification Differences?
-
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 -
It could be that Tiger is using -release in some place where Leopard is
using -autorelease. Either way is legitimate, but it would lead to the
kinds of effects that you're seeing.
If you follow the Cocoa memory management guidelines, it shouldn't
matter either way…
John Nairn wrote:
> 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
-
On Feb 8, 2008, at 1:58 PM, John Nairn wrote:
> 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?
There were some changes in NSWindowController between Tiger and
Leopard. See the "New Behavior in NSWindowController at Window Closing
Time" and "Bug Fixes in -[NSWindowController dealloc]" sections in the
Leopard AppKit release notes at http://developer.apple.com/releasenotes/Cocoa/AppKit.html
. In a couple of places it's not releasing instead of autoreleasing.
Hopefully that explains what you're seeing.
-- Mark -
On Feb 8, 2008, at 2:47 PM, Mark Piccirelli wrote:
> In a couple of places it's not releasing instead of autoreleasing.
> Hopefully that explains what you're seeing.
In a couple of places it's _now_ releasing instead of autoreleasing, I
meant to write.
-- Mark -
On Feb 8, 2008, at 2:47 PM, Mark Piccirelli wrote:
> On Feb 8, 2008, at 1:58 PM, John Nairn wrote:
>
>> 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?
>
> There were some changes in NSWindowController between Tiger and
> Leopard. See the "New Behavior in NSWindowController at Window
> Closing Time" and "Bug Fixes in -[NSWindowController dealloc]"
> sections in the Leopard AppKit release notes at http://developer.apple.com/releasenotes/Cocoa/AppKit.html
> . In a couple of places it's not releasing instead of autoreleasing.
> Hopefully that explains what you're seeing.
>
I had my previous post in slightly the wrong order, but the correct
order is explained by Apple's release notes which say:
"the window controller itself is now released instead of autoreleased"
In Leopard, closing my window controller and sending a message goes as
follows:
1. window controller is deallocated (because of the new release rule)
2. The scheduled method is invoked
3. The interface objects are released (because they are still
autoreleased)
In Tiger this went (corrected order from my previous post)
1. The scheduled method is invoked
2. The window controller is deallocated (because it was autoreleased
in Tiger)
3. The interface objects are released (autoreleased)
My code was sensitive to some methods being called in the middle of
releasing the window, its controller, and its objects. In Tiger this
releasing was always together (sounds like all were autoreleased), but
in Leopard the controller is released while nib objects are
autoreleased.
---------------
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
