On Feb 10, 2009, at 10:30 AM, Michael Ash wrote:
I downloaded the example, ran it, and reproduced the crash.
I then enabled zombies and ran it again. The crash message said:
2009-02-10 13:27:16.566 DocumentTest[97982:813] ***
-[MyWindowController tableView:objectValueForTableColumn:row:]:
message sent to deallocated instance 0x18ea40
Precisely as I had predicted.
Connected it in the nib, then implemented -dealloc:
Crash went away, again exactly as predicted.
Right.
The problem is that the window controller gets sent release like
normal, it release its top-level object like normal (the window), but
the window does not get deallocated because it's setOneShot:NO. The
window still retains the views, thus causing the table view to hit up
the now-deallocated data source.
What's "wrong" about this to me, is that setOneShot says it determines
whether or not the window *backing* is freed, not the NSWindow object
itself. So why does setOneShot:NO /seem/ to cause an extra retain on
the NSWindow? A quick test shows that either way, the retain count on
the window is 5 before [super dealloc], but clearly the window is
being deallocated after the window controller instead of before, such
as when setOneShot:YES.
The behavior of non-one shot windows is obviously not clear.
--
Seth Willits
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
