Closed Bug 704866 Opened 13 years ago Closed 13 years ago

Firefox Crash [@ firefox@0x1 ] [@ -[NativeMenuItemTarget menuItemHit:] ]


(Core :: Widget: Cocoa, defect)

Not set





(Reporter: marcia, Assigned: smichaud)


(Keywords: crash)

Crash Data


(1 file)

Seen while looking at crash stats. Both sigs seem to be related. First signature appears in 8.0 and 8.01, Mac only - Most crashes appear to be startup crashes.

Frame 	Module 	Signature [Expand] 	Source
0 	firefox 	firefox@0x1 	
1 	XUL 	-[NativeMenuItemTarget menuItemHit:] 	widget/src/cocoa/
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/
7 	AppKit 	-[NSWindow sendEvent:] 	
8 	XUL 	-[ToolbarWindow sendEvent:] 	widget/src/cocoa/
9 	AppKit 	-[NSApplication sendEvent:] 	
10 	XUL 	-[GeckoNSApplication sendEvent:] 	widget/src/cocoa/
11 	AppKit 	-[NSApplication run] 	
12 	XUL 	nsAppShell::Run 	widget/src/cocoa/
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[NativeMenuItemTarget%20menuItemHit:] seems to have a mix of Firefox and Thunderbird crashes but a very similar signature:

Frame 	Module 	Signature [Expand] 	Source
0 	XUL 	-[NativeMenuItemTarget menuItemHit:] 	widget/src/cocoa/
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/
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:] ]
Attached patch Hacky fixSplinter Review
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)
Attachment #577780 - Flags: review?(bgirard) → review+
Landed on mozilla-inbound:
Whiteboard: [inbound]
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
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.