On Feb 23, 2013, at 9:57 PM, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote:
> On Feb 23, 2013, at 18:12 , Andy Lee <ag...@mac.com> wrote: > >> Also, to repeat part of Graham's question: is the window you're attaching >> the sheet to a floating window or a regular window? Maybe the sandboxing is >> irrelevant. >> >>> How do you run it as a panel standalone - as opposed to as a sheet ? >> >> I don't remember the method name offhand, but you'll find it if you look at >> the docs for NSSavePanel. If you try it and the crash goes away, please let >> us know -- I'm curious. > > Peter didn't run it as a sheet. You can see in line 30 of the backtrace that > his app invoked -[NSSavePanel runModal]. Ah, right. I'm puzzled by the question then. > Also, according to the backtrace, the crash occurred in Cocoa frameworks > (well, Apple frameworks, since it's in C++ code), so I wouldn't hare off > looking for app memory management errors without any evidence supporting the > idea. Can you say more about this? I thought it was possible for a memory error -- especially a dangling pointer -- to have a delayed effect such that there's no telling when it will cause a crash. Is there something about these particular symptoms and this stack trace, besides the fact that it happens in Apple's code, that rules out (or makes very unlikely) an error in Peter's code? Perhaps the fact that it's so repeatable? > Rather, I think Graham's closer to being on the correct track. I've noticed > that 10.8 NSSavePanel does have a tendency to explode, for reasons that are > unclear. When it does that, it continues to explode until you find a way of > getting it past the triggering condition. After that, it behaves properly > until the next time. > > My guess is that 10.8 re-architected NSSavePanel (to better support > sandboxing, but affecting non-sandboxing too) in such a way that there is > persistent state stored outside the application. For that reason, quitting > the app doesn't necessarily clear the problem. > > My guess is that in Peter's case the popup contains an entry that is no > longer valid. It's possible that clicking the Save button without popping up > the menu will clear it, or perhaps using the Save panel of a different > application, or rebooting. Or possibly there's a preferences file that could > be deleted. > > That's all speculation, But plausible. > but given the backtrace there's really no evidence the crash is Peter's fault. This falls a little short of saying it's definitely not caused by a bug in Peter's code, so I'd like to be clear: is that what you're saying, and if so, can you explain a bit more? --Andy _______________________________________________ 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
