On Feb 23, 2013, at 20:46 , Jon Gary <j...@ambrosiasw.com> wrote: > Just because a crash happens in an apple framework doesn't mean it's note our > bug. If you can't take the time to run the code with zombies on, it's a > waste of everyone else's time guessing what's going on.
Sure, I wasn't intending to suggest this would be useless. Rather, I was trying to suggest that a good place to start is with whatever can be gleaned from the evidence. On Feb 23, 2013, at 19:44 , Andy Lee <ag...@mac.com> wrote: > Ah, right. I'm puzzled by the question then. I suspect it was just a misunderstanding. > 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? I guess I was saying two independent things: 1. The backtrace doesn't really look like a memory management error in developer code, which we see quite a lot of on this list. It's very cleanly in Apple's code. Looking at the method/function names in BT lines 1-3, it appears to be trying to find out whether a certain file can be opened by the calling app, and I'd guess it's setting up to call something in Launch Services. Given that it's in a popup in a save panel, it seems a bit implausible to me that this is going to depend on an object owned by the app itself, though of course that's possible. If we wanted to go further out on a limb to speculate, it's worth noting that the crash was in an autorelease, but that doesn't help much. The invalid address (according to "VM Regions Near…", which I've never actually seen before, I think), isn't *in* an allocated VM region, which suggests it's random garbage, not a pointer to a freed object, but of course that's possible too. About the only plausible way an app's code might affect something like this, which is straightforwardly deep in NSSavePanel code, might be if there was an accessory view doing something wrong. But even then, it seems unlikely that merely popping up a standard menu control would crash like this. 2. I have actually, maybe 3-4 times since 10.8 was released, had a non-sandboxed app crash on displaying an open/save panel, though not this particular crash. Such crashes are repeatable until you futz around in the panel to get past them, then they disappear without a trace. I've never found an iota of evidence that the application code was at fault. So perhaps my history prejudices me towards blaming the NSSavePanel code. _______________________________________________ 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
