On May 8, 2016, at 13:19, Quincey Morris <quinceymor...@rivergatesoftware.com>
wrote:
If you look at your backtrace again, you’ll see that it crashed doing
something with rows. It’s as likely trying to message your data source as your
delegate. You should nil that as well. Note that it’s not necessarily that any
particular object has or hasn't been deallocated, but there’s a whole network
of objects that may have now-invalid references somewhere. (In this case, it
looks like the reference to a table cell view that’s crashing.)
Also consider delegate (and similar) references to view controllers and
window controllers. IIRC, the window itself may not be deallocated immediately
after being closed, because it’s kept alive until the window server (a
difference process) gets around to cleaning up after it, and so it might take a
few iterations of your run loop before the window object goes away. That in
turn might keep alive other controller/delegate objects that your app has
otherwise finished with.
The trick to solving this is to find just the right weak reference to
nil.
Spot on. The NSViewController is both the delegate and the dataSource of the
table view, and nil-ing both of them (rather than just the delegate) in
-windowWillClose: seems to have done the trick.
Good to know we need to keep an eye out for non-zeroing delegate references in
other areas as well -- we just assumed they had all been converted to zeroing
references post-ARC, but it appears the old saying about assumptions continues
to hold...
Thanks for the help!
Matt
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
