435521 - Crash in [@ GeckoNSMenu performKeyEquivalent] when rapidly cycling DM window

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P1)

Description

[Marcia Knous [:marcia]]

Seen while testing Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0.

STR:
1. Populate Download Manager with about 50-60 downloads.
2. While the list is loading rapidly press the Command and J key.
3. Crash. Report is http://crash-stats.mozilla.com/report/index/36f8be63-292d-11dd-9874-001a4bd46e84?p=1

I may have been holding down the Command J and rapidly pressing the J key, but I am not 100% sure.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Marcia, your report seems plausible ... but I can't reproduce it.  (I
tested on OS X 10.5.2 with about 50 items in the Download Manager
window.  I held down 'command' while rapidly pressing 'j'.)

Are you able to reproduce it at will?  If so, can you tell me more
about what you need to do to make the crashes happen?

Comment 2

[Marcia Knous [:marcia]]

Steven: I believe that Stephen was able to reproduce it rather easily. One thing we noticed while trying to get it to crash on Friday is when it doesn't, the "Tools" menu item flashes and we could no longer open the Download Manager window.

Comment 3

[Samuel Sidler (old account; do not CC)]

This crash (at the address in Marcia's crash report) accounts for about 45 of the ~5200 reports [@ nsObjCExceptionLogAbort(NSException*)].

fwiw, I *can't* reproduce, but stephend definitely can (I watched!). He's on 10.4, but Marcia was on 10.5 when she reported. For me (on 10.5), the key command just stops working eventually while holding it down and the download manager no longer shows/disappears.


For posterity:

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	XUL 	nsObjCExceptionLogAbort 	mozilla/widget/src/cocoa/nsMenuBarX.mm:138
1 	XUL 	-[GeckoNSMenu performKeyEquivalent:] 	mozilla/widget/src/cocoa/nsMenuBarX.mm:977
2 	AppKit 	-[NSApplication _handleKeyEquivalent:] 	
3 	AppKit 	-[NSApplication sendEvent:] 	
4 	AppKit 	-[NSApplication run] 	
5 	XUL 	nsAppShell::Run 	mozilla/widget/src/cocoa/nsAppShell.mm:591
6 	XUL 	nsAppStartup::Run 	mozilla/toolkit/components/startup/src/nsAppStartup.cpp:181
7 	XUL 	XRE_main 	mozilla/toolkit/xre/nsAppRunner.cpp:3170
8 	firefox-bin 	main 	mozilla/browser/app/nsBrowserApp.cpp:158
9 	firefox-bin 	start 	crt.c:272
10 	firefox-bin 	start 	
11 		@0x0 	

Comment 4

[Samuel Sidler (old account; do not CC)]

I lied. I can reliably reproduce this using Firefox 3 RC 1 but less-reliably reproduce it using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008052704 Minefield/3.0pre (the latest nightly). It's still reproducible, but it's more common for me to get the "key command stop working" bug than the crash.

RC1: bp-3a2e09a8-2c33-11dd-b314-001a4bd46e84
Nightly: bp-6ca9e5c0-2c33-11dd-b9c4-001cc45a2c28

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Now I've got it -- I can reproduce the crashes if I press 'command'
and then _hold down the 'j' key_ (which of course makes it repeat).

Comment 6

[Steven Michaud [:smichaud] (Retired)]

I see 562 of these crashes in Firefox 3 over the last 10 days.  So
this is actually a topcrasher (though not in the top 10).

http://crash-stats.mozilla.com/?do_query=1&version=Firefox%3A3.0&platform=mac&query_search=stack&query_type=exact&query=-%5BGeckoNSMenu+performKeyEquivalent%3A%5D&date=&range_value=10&range_unit=days

Comment 7

[Steven Michaud [:smichaud] (Retired)]

Many of these 562 aren't exactly the same crash (they have somewhat
different stacks).  But there's a chance that if I can fix this one
(which is likely since I can now reproduce it), the others may get
fixed too.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

Attachment: Gdb stack trace (made with debug symbols)

Here's a gdb stack trace of the assertion that triggers the crash, and
then of the crash itself.

(I find the crashes easier to reproduce if I first maximize the
Download Manager window.  Then I just press 'command' and hold down
the 'j' key.)

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix (hg)

I've finally had a chance to get back to this.

Here's a fix.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix (cvs)

And here's a tryserver build made with the cvs patch:

https://build.mozilla.org/tryserver-builds/2008-07-16_15:[e-mail]-bugzilla435521-cvs/[e-mail]

(I tried but failed to do an hg tryserver build.  The tryserver now
claims to support building from hg patches ... but apparently that's
not quite true yet.)

Marcia (and others), please try this build and let me know your
results.

Comment 11

[Marcia Knous [:marcia]]

Steven: In my initial test running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.2pre) Gecko/2008071615 Minefield/3.0.2pre, things looked very smooth when cycling rapidy through DM. I compared this to the FF 3.0.1 build, where I was quite easily able to get in a funky state (no crash) after a few key cycles. More tests to come on PPC and Tiger, but so far this looks good.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix rev1 (revise comments)

Comment 13

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix rev1 cvs (revise comments)

I've done more tests and found a much stronger reason to avoid
returning nil from [GeckoNSMenu itemAtIndex:] -- doing so quickly
causes the cmd-j key combination to stop working.  So I've revised my
comments.  The code hasn't changed.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Attachment: Gdb trace (with debug symbols) of different crash on OS X 10.4.11

Testing on OS X 10.4.11, I found that you can still crash (in a
slightly different location), even with my current patch.  So I'll need
to revise the patch.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

Sorry, I forgot about this.

I'll get back to working on it.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

I can no longer reproduce this, either on trunk or on the 1.9.0 branch
(in the equivalent of Monday's nightlies, testing on OS X 10.5.5).

Can you, Marcia?  Or anyone else?

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #16)
> I can no longer reproduce this, either on trunk or on the 1.9.0 branch
> (in the equivalent of Monday's nightlies, testing on OS X 10.5.5).
> 
> Can you, Marcia?  Or anyone else?

Yes, both of us can, using Minefield; it crashes within ~ 3 or so seconds.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

Actually, I *can* still reproduce it.  It's just gotten a lot harder
to do so in gdb.

Besides what I already described in comment #8, here's what I
(apparently) need to do in addition:  After holding down cmd-j for a
while, let go the cmd key (while still holding down the j key).  Then
press down the cmd key again and hold it.  Then let go the j key
(while still holding down the cmd key) and press it (the j key) down
again (and hold it).  A few cycles of this are sufficient to give me a
crash (even running in gdb).  Go figure.

Comment 19

[Steven Michaud [:smichaud] (Retired)]

This bug's crash can also be reproduced using the second STR
(00a5308a-fdf6-4b20-a5f6-93b762090210) in bug 477475 comment #9.

Comment 20

[Steven Michaud [:smichaud] (Retired)]

Marcia and Stephen:

Josh's patch from bug 477475 comment #30 (with tryserver build) might also fix this bug.  Please try it out and let us know.

Of course, please also make sure you can still reproduce this bug in current nightlies.

Comment 21

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #20)

1) Still able to reproduce the crash using today's Shiretoko nightly on 10.4 at will.
2) Using Josh's tryserver build from bug 477475 comment #30, I no longer can reproduce the crash (but there are various other problems remaining such as being unable to bring up the Downloads window, and/or being able to type in the location bar, however those are separate issues).

Comment 22

[Steven Michaud [:smichaud] (Retired)]

Stephen, please test with today's Minefield nightly.

Tryserver builds are based on trunk code, so that needs to be the baseline for your tests.

Comment 23

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #22)
> Stephen, please test with today's Minefield nightly.
> 
> Tryserver builds are based on trunk code, so that needs to be the baseline for
> your tests.

Sure, ok: http://crash-stats.mozilla.com/report/index/29ab3033-d5ad-4243-8cc8-2f0c32090218?p=1; trunk still crashes there.

Comment 24

[Sheila Mooney]

I searched for the past 4 weeks and all crashes are in some version of 3.0. Since there is nothing in a current version, resolving as fixed.