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 20:14:28 -0700
On Jul 29, 2013, at 19:33 , Lee Ann Rucker <email@hidden> wrote:
> I've just hit this too, and my best guess as to why it's so reproducible for me but this is the *only* mention that Google can find is that my window does trigger updates to one of its restorable values early in its lifetime. Unfortunately that's unavoidable.
>
> I just gave up and dropped the restorableStateKeyPaths.
> On Aug 24, 2012, at 6:17 PM, Eric Wing wrote:
>
>> But my app also allows the main window (and controller) to be
>> destroyed while running and I create a new instance of the two.
>> Sometimes my app crashes several seconds after this happens. The crash
>> always happens in background thread like so:
>>
>> Crashed Thread: 8 Dispatch queue: NSPersistentUI Work
>>
>> Thread 8 Crashed:: Dispatch queue: NSPersistentUI Work
>> 0 libobjc.A.dylib 0x00007fff906c02d0 objc_msgSend + 16
>> 1 com.apple.Foundation 0x00007fff8d4f3386 probeGC + 80
There are a couple of interesting points here. Perhaps the appearance of 'probeGC' in Eric's backtrace suggests he's using garbage collection. Are you doing so too? If not, then it wouldn't be surprising that the crash is more reproducible for you. Eric was racing garbage collection for a zombie access. For a non-GC app, you always lose the race before it even starts.
Secondly, this has all the appearance of a memory management error, though of course that's not necessarily conclusive. In Eric's narrative, the crash occurs with a zombie *window controller*, but he doesn't mention the status of the window at that moment.
If the window is also deallocated at that point, this seems like a bug in state restoration (attempting to save state for a window that no longer exists).
However, if the window is not yet deallocated -- and remember that the window server may keep the NSWindow object alive after your app has no references to it -- the question is what is keeping the window controller alive until the window's actual deallocation? Well, in this case, until the window's state is actually saved.
If the relationship between the window and window controller is not explicitly broken (e.g. by clearing window.delegate, or whatever the frameworks use to keep the two associated), then it may be the window's responsibility to keep the window controller alive. That's normally something you wouldn't regard as desirable, because it probably implies a deliberate retain cycle that would have to be broken manually at (say) NSWindow dealloc. Under these circumstances, there might be an argument that the app is at fault for not keeping the window controller alive.
(Well, that would be the memory management situation for ARC or MRR. For GC, the equivalent problem would be the lack of a strong reference from the window back to the window controller.)
All of the above mostly represents speculation, but it might be that you have an extremely subtle memory management bug in your own code.
_______________________________________________
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