Re: Trying to understand/prevent crash using restorableStateKeyPaths in NSPersistentUI Work
Re: Trying to understand/prevent crash using restorableStateKeyPaths in NSPersistentUI Work
- Subject: Re: Trying to understand/prevent crash using restorableStateKeyPaths in NSPersistentUI Work
- From: Quincey Morris <email@hidden>
- Date: Mon, 29 Jul 2013 22:43:52 -0700
On Jul 29, 2013, at 22:05 , Lee Ann Rucker <email@hidden> wrote:
> The repro case is to close the document and then reopen it. It doesn't reopen the windows, it makes a new window of the same class as the old one. Looking at Instruments right now I have one new window and windowController - stopped in the window creation code - and one old window that would've been dealloc'ed if the code had just run a bit longer.
So that really does sound like a memory management problem -- the old window controller is deallocated while another thread is preparing to tell it to save its restorable state -- but it's not all clear at what level the problem exists (app or frameworks). Perhaps the new window creation is irrelevant except to the extent that it might delay the other-threaded save of restorable state.
For what its worth, I have state restoration working without crashes in an ARC app. I use the 'encodeRestorableStateWithCoder' approach to save the frame rect (for the purpose Eric described), and there is a bit of extra complexity because I'm restoring the state for a multiple-window-of-the-same-type-per-document app. The complexity is in the NSDocument subclass, not the window controller.
I remember I had a lot of trouble with the state restoration, but I don't recall any of it being due to the kind of crash you're seeing -- it was a year or more ago that I was working on it.
The only thing I can suggest, if you're still interested in experimenting, would be to try deferring the release of the window controller to the next iteration of the run loop (or, even more bluntly, to leak all the window controllers for the purpose of testing) and see if the crash disappears. You might at least find a workaround if you can defer deallocation for just long enough.
_______________________________________________
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