Re: Mysterious crash with NSTableView
Re: Mysterious crash with NSTableView
- Subject: Re: Mysterious crash with NSTableView
- From: Quincey Morris <email@hidden>
- Date: Fri, 26 Aug 2016 13:06:34 -0700
- Feedback-id: 167118m:167118agrif8a:167118spz-PuKj6g:SMTPCORP
On Aug 26, 2016, at 11:39 , Andreas Falkenhahn <email@hidden> wrote:
>
> From a logical point of view I'd expect this call
>
> [win release];
>
> to kill off the NSTableView and its associates completely. So I'd consider
> it safe to …
Welcome to the latest episode of “It’s Deja Vu All Over Again!”. We used to have these sorts of discussions on this list all the time, until ARC, at which point they pretty much stopped.
Reasoning about retain counts is extremely difficult, and common sense will lead you astray.
In particular, you’re confusing “release” with “deallocate”, which is something we all did back in the days when we didn’t use ARC. The concept of releasing the “last” reference to an object, the “one” that’s “keeping it alive” is going to get you in all sorts of trouble.
> I mean, who the heck is referencing those delegates after the call to [win release]?
A careful reading of the documentation will tell you that windows are managed by a window manager process that’s separate from yours. It will keep windows alive until it gets a chance to remove them from its own data structures, which may not happen until the next iteration of your run loop.
But even if that weren’t true, the assumption that the table view object won’t outlive the window object is invalid.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden