> On 21 May 2015, at 12:42 pm, Graham Cox <graham....@bigpond.com> wrote: > > I was able to record the problem running the app this way. That’s the good > news. The bad news is that I’m not really any the wiser. NSDocument is a > complex object that has become somewhat intractable of late. While I see the > same stack trace in Instruments that I get anyway, it’s not obvious that > that’s the problem - it could be any previous release that’s incorrect. It’s > a bit weird that I can’t reproduce it running under Xcode though - if it’s a > straightforward overrelease, this should always reveal itself shouldn’t it? > It always has in the past. >
Reasoning about this - I don’t think it’s a simple over-release. It’s more of a race condition. The steps to reproduce (in my app) are simple enough - open a document, dirty it, close it. I need to have the system pref setting that prompts to save changes on an untitled close, so that the save panel shows. I don’t save. I also need to have the Font Panel open during the close sequence. If I don’t show the Font panel, or if I hide it during close and reshow it, the app doesn’t crash - everything is cleaned up properly and all is well. It also doesn’t seem to occur if the app isn’t sandboxed - the app that’s exhibiting the problem is sandboxed, but the unsandboxed version of same does not. Looking at the zombie situation, if at that time the window is still alive but its document has gone, then the window.windowController.document reference is stale. But the window has been closed already - that’s what closed the document. So we must be looking at a moment in time between the deallocation of the document but before the associated window has been deallocated. The window goes away shortly afterwards, probably when the main autorelease pool is drained. The stack trace shows that it’s the Font Panel that’s sending one of its annoying noisy messages to the responder chain at the time the zombie is referenced - this must be sneaking in between the doc dealloc and the window dealloc, and boom. If it’s a timing/race issue like this, that may well be why I’m not seeing it when I’m running in the debugger. I can reproduce it if I build using the release scheme rather than the debug one. Could that suggest a bug in the optimizer? I still don’t understand why the Font Panel has to be so obnoxious, querying the responder chain on every single event, including mouse moved. It does not appear to use that information in any way that’s visible in the UI. Another bug? However, if this were just as simple as a race, sadly I’m not able to reproduce it in a separate simple doc-based test app (sandboxed and built for release), so that comes back to me making a mistake… —Graham _______________________________________________ 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
