Closed Bug 704866 Opened 9 years ago Closed 9 years ago
Firefox Crash [@ firefox@0x1 ] [@ -[Native
Menu Item Target menu Item Hit:] ]
Seen while looking at crash stats. Both sigs seem to be related. First signature appears in 8.0 and 8.01, Mac only - https://crash-stats.mozilla.com/report/list?signature=firefox@0x1. Most crashes appear to be startup crashes. Frame Module Signature [Expand] Source 0 firefox firefox@0x1 1 XUL -[NativeMenuItemTarget menuItemHit:] widget/src/cocoa/nsMenuBarX.mm:857 2 AppKit -[NSApplication sendAction:to:from:] 3 AppKit -[NSMenuItem _corePerformAction] 4 AppKit -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] 5 AppKit -[NSMenu performKeyEquivalent:] 6 XUL -[ChildView keyDown:] widget/src/cocoa/nsChildView.mm:3962 7 AppKit -[NSWindow sendEvent:] 8 XUL -[ToolbarWindow sendEvent:] widget/src/cocoa/nsCocoaWindow.mm:2396 9 AppKit -[NSApplication sendEvent:] 10 XUL -[GeckoNSApplication sendEvent:] widget/src/cocoa/nsAppShell.mm:192 11 AppKit -[NSApplication run] 12 XUL nsAppShell::Run widget/src/cocoa/nsAppShell.mm:771 13 XUL nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:224 14 XUL XRE_main toolkit/xre/nsAppRunner.cpp:3544 15 firefox main browser/app/nsBrowserApp.cpp:198 16 firefox firefox@0xac3 The other signature https://crash-stats.mozilla.com/report/list?signature=-[NativeMenuItemTarget%20menuItemHit:] seems to have a mix of Firefox and Thunderbird crashes but a very similar signature: https://crash-stats.mozilla.com/report/index/d1e1efb1-bddd-4514-a5f4-071822111118 Frame Module Signature [Expand] Source 0 XUL -[NativeMenuItemTarget menuItemHit:] widget/src/cocoa/nsMenuBarX.mm:857 1 AppKit -[NSApplication sendAction:to:from:] 2 AppKit -[NSMenuItem _corePerformAction] 3 AppKit -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] 4 AppKit -[NSMenu _internalPerformActionForItemAtIndex:] 5 AppKit -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] 6 AppKit NSSLMMenuEventHandler 7 HIToolbox HIToolbox@0x77f6 8 HIToolbox HIToolbox@0x6d45 9 HIToolbox HIToolbox@0x24a80 10 HIToolbox HIToolbox@0x53c34 11 HIToolbox HIToolbox@0x80a09 12 HIToolbox HIToolbox@0x809c1 13 HIToolbox HIToolbox@0x808d1 14 HIToolbox HIToolbox@0x61c26 15 HIToolbox HIToolbox@0x6137b 16 AppKit _NSHandleCarbonMenuEvent 17 AppKit _DPSNextEvent 18 AppKit -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 19 AppKit -[NSApplication run] 20 XUL nsAppShell::Run widget/src/cocoa/nsAppShell.mm:746 21 XUL nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:218 22 XUL XRE_main toolkit/xre/nsAppRunner.cpp:3754 23 firefox-bin main browser/app/nsBrowserApp.cpp:158 24 firefox-bin firefox-bin@0x953
These crashes go back at least as far as FF 4. They're low volume -- 96 in the last 4 weeks. I'd guess they're happening on access to a deleted NativeMenuItemTarget object. (Note that a number of comments report crashes on quit.) It'll probably be a while before I can get to this.
Version: 9 Branch → unspecified
Should we ducktape this crash away with some aggressive null check in the mean time?
I don't know, and it'll take me at least an hour or two digging through the code to find out. But access to bugzilla has been troublesome all day, which blocks the rest of my work. So I'll spend the next couple of hours looking into this :-)
Assignee: nobody → smichaud
Summary: Firefox Crash @ firefox@0x1 → Firefox Crash [@ firefox@0x1 ] [@ -[NativeMenuItemTarget menuItemHit:] ]
In my enforced "idleness", I've been able to figure out the likely cause of this bug, and how to fix it. The crashes aren't caused by accessing a deleted NativeMenuItemTarget object (we appear to never delete those). Instead it seems that menuGroupOwner (an nsMenuGroupOwnerX object) might have been deleted. An nsMenuGroupOwnerX object is always also an nsMenuBarX object, which (as a comment warns above its class definition in nsMenuBarX.h) can become invalid whenever its DOM node is destroyed. This patch is a hack. As my patch comment says, fixing this bug properly might trigger delays as windows/tabs are closed. My hack avoids these (potential) delays. If it doesn't fix enough of these crashes, or if it causes problems of its own, we'll need to risk the delays. But I think it's worth trying my hack out on the trunk for a while, to see if it helps.
Attachment #577780 - Flags: review?(bgirard)
Landed on mozilla-inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/6552a4bba94a
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
There haven't been any of these crashes on the trunk since my patch landed. So it seems to be working.
You need to log in before you can comment on or make changes to this bug.