Seen while testing Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0.
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.
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?
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.
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.
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
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.
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).
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).
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
Created attachment 322822 [details]
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.)
Created attachment 329924 [details] [diff] [review]
I've finally had a chance to get back to this.
Here's a fix.
Created attachment 329925 [details] [diff] [review]
And here's a tryserver build made with the cvs patch:
(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
Steven: In my initial test running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:184.108.40.206pre) 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.
Created attachment 330585 [details] [diff] [review]
Fix rev1 (revise comments)
Created attachment 330586 [details] [diff] [review]
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.
Created attachment 330782 [details]
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.
Sorry, I forgot about this.
I'll get back to working on it.
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?
(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.
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.
This bug's crash can also be reproduced using the second STR
(00a5308a-fdf6-4b20-a5f6-93b762090210) in bug 477475 comment #9.
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.
(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).
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.
(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.
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.