320998 - Crash [@ 0xfffeff20 / 0xfffeff18] (often @CFDictionaryAddValue) when selecting an item from a menu

Status: RESOLVED WORKSFORME

(Firefox :: Menus, defect)

Description

[Uri Bernstein]

This is currently the top Mac crash on the Firefox 1.5 reports.
The stacks are various, but many of them contain CFDictionaryAddValue() as the second frame.
The comments mostly indicate trying to select a bookmark, view source, or open preferences. From my personal expirience, it can happen whenever selecting any menu item (it happened to me with various different menus / items).

Comment 1

[Uri Bernstein]

Sample stack trace (from TB13136433):

0xfffeff20
CFDictionaryAddValue()
DrawTheMenu()
MenuChanged()
TrackMenuCommon()
MenuSelectCore()
MenuSelect()
nsMacMessagePump::DoMouseDown()
nsMacMessagePump::DispatchEvent()
nsMacMessagePump::DoMessagePump()
nsAppShell::Run()  [/builds/tinderbox/Fx-Mozilla1.8/Darwin_7.9.0_Depend/mozilla/widget/src/mac/nsAppShell.cpp, line 114]
nsAppStartup::Run()   
XRE_main()  [/builds/tinderbox/Fx-Mozilla1.8/Darwin_7.9.0_Depend/mozilla/toolkit/xre/nsAppRunner.cpp, line 2315]
_start()   
start()

Notice the menu-related frames on the stack.

Comment 2

[Uri Bernstein]

Nominating for 1.8.0.1, as a topcrash.

Comment 3

[Simon Fraser [no longer active]]

Maybe a ref counting bug?

Comment 4

[Mark Mentovai]

Uri, or others experiencing this crash:

Does the crash occur when you're using menus while the browser is supposed to be doing something else (such as loading a page), or does it happen even when the browser is quiescent?

Comment 5

[Uri Bernstein]

(In reply to comment #4)
> Uri, or others experiencing this crash:
> 
> Does the crash occur when you're using menus while the browser is supposed to
> be doing something else (such as loading a page), or does it happen even when
> the browser is quiescent?

As far as I remember, it happens when nothing else is going on. However, I tend to have lots of open tabs, so I can't say for sure that nothing was happening on any of them (such as auto-reloading).

Comment 6

[Mark Mentovai]

I've yet to crash here.  How often is this happening?

Comment 7

[Uri Bernstein]

(In reply to comment #6)
> I've yet to crash here.  How often is this happening?

To me it happened 5 (maybe 6) times in about two months (some of these were with pre-1.5 nightlies/RCs). This was the only type of crash I encountered during this period.

The high position on the crash reports suggests that it happens relatively frequently to others as well.

Comment 8

[Daniel Veditz [:dveditz]]

Would love a fix for this topcrash, but at this point I'm not sure it's realistic to block on it since no apparent progress has been made.

Comment 9

[Daniel Veditz [:dveditz]]

If there's any hope of getting this into any 1.8.0.x a good first step would be assigning this to someone.

Comment 10

[Jo Hermans]

*** Bug 323045 has been marked as a duplicate of this bug. ***

Comment 11

[Alessio]

(In reply to comment #4)
> Uri, or others experiencing this crash:
> 
> Does the crash occur when you're using menus while the browser is supposed to
> be doing something else (such as loading a page), or does it happen even when
> the browser is quiescent?

to me, it happens only when a page is loading, and not on all the pages... it happens especially on a web page (but i can't give the url since it's private)
(see bug #323045)

Comment 12

[Uri Bernstein]

This has not happened to me even once since my last comment, so I was hoping that it somehow got fixed on the way to 1.5.0.1. However, a quick look at talkback reports shows that this is still the #1 Mac crash with 1.5.0.1, with well over twice as many crashes as the second crasher on the list.

The only other thing I can think of that changed for me in the last weeks is that I stopped using the Googlebar extension (replaced it initially by the official Google toolbar, and later by Googlebar Light). It's a long shot, but I thought I'd mention it anyway.

Comment 13

[Daniel Veditz [:dveditz]]

blocking 1.8.0.2 denied, not a regression, no trunk-baked patch.

Comment 14

[Uri Bernstein]

(In reply to comment #13)
> blocking 1.8.0.2 denied, not a regression, no trunk-baked patch.

Not that I disagree with the bottom line, but as far as I can tell this *is* a regression from 1.0.x. The 1.0.7 crash reports show no crashes @0xfffeff20, and only a handful of crashes @0xfffeff18, which do not seem to be menu-related.

Comment 15

[Mark Mentovai]

This is the Mac topcrasher and I'd really very much like to see it fixed.  Unfortunately, I haven't been able to reproduce it, at all, ever.  Since the stack alone is obviously useless, a good next step would be for someone who does crash here to get a core dump for this crash and give it to me.

Turning on core dumps, figuring out whether a specific crash is actually THIS crash, and then picking the correct dump to send is slightly technically intensive.  Start here: http://developer.apple.com/technotes/tn2004/tn2124.html#SECCOREDUMPS , and remember that you can use CrashReporter to determine whether your crash is at 0xfffeff20 or not.  If you get a dump, please let me have it, let me know what build it's from and what OS version you were running, and attach the accompanying CrashReporter log with the useless stack.

Comment 16

[Christopher Kintner]

I emailed Mark a couple of days ago about the availability of a core dump (TB15226755Q) for possibly this bug. I haven't heard back from him yet so I am posting it here. Unfortunately Firefox was not in a clean state when the crash occurred; I was watching a video off of comedycentral.com while in another window I was loading a bookmark into a tab that had a java applet in it. The coredump is huge 764MB (142MB compressed). Let me know if you want me to post it somewhere on the web. I only remember experiencing this crash when loading a bookmark into a new tab while other tabs are still loading in the background. I cannot, however, reproduce this crash on demand.

Christopher

Parital stack trace:
0   <<00000000>>        0xfffeff20 objc_msgSend_rtp + 32
1   com.apple.CoreFoundation            0x90748e0c CFDictionaryAddValue + 148
2   com.apple.HIToolbox                 0x93225c1c
SendMenuOpening(MenuSelectData*, MenuData*, double, unsigned long,
__CFDictionary*, unsigned char, unsigned char*) + 312
3   com.apple.HIToolbox                 0x9322580c
DrawTheMenu(MenuSelectData*, __CFArray**, unsigned char*) + 164
4   com.apple.HIToolbox                 0x93225674
MenuChanged(MenuSelectData*) + 432
5   com.apple.HIToolbox                 0x932252dc
TrackMenuCommon(MenuSelectData&, unsigned char*) + 608
6   com.apple.HIToolbox                 0x932230bc
MenuSelectCore(MenuData*, Point, double, unsigned long,
OpaqueMenuRef**, unsigned short*) + 188
7   com.apple.HIToolbox                 0x93222c7c MenuSelect + 100
8   org.mozilla.firefox                 0x0069510c
nsMacMessagePump::DoMouseDown(EventRecord&) + 268
9   org.mozilla.firefox                 0x00694e60
nsMacMessagePump::DispatchEvent(int, EventRecord*) + 192
10  org.mozilla.firefox                 0x00694ce8
nsMacMessagePump::DoMessagePump() + 64
11  org.mozilla.firefox                 0x003008a0 nsAppShell::Run() + 56
12  org.mozilla.firefox                 0x003a0628 nsAppStartup::Run() + 60
13  org.mozilla.firefox                 0x00014338 XRE_main + 3792
14  org.mozilla.firefox                 0x0000f6a8 start + 432
15  org.mozilla.firefox                 0x0000f528 start + 48

Comment 17

[Mark Mentovai]

Interesting that Java was running at the time of the crash.  Have others crashed here with Java or other plugins running?

Comment 18

[Mark Mentovai]

0   <<00000000>>        0xfffeff20 objc_msgSend_rtp + 32
1   com.apple.CoreFoundation            0x90748e0c CFDictionaryAddValue + 148
...
7   com.apple.HIToolbox                 0x93222c7c MenuSelect + 100

Oh, right, of course!  0xfffeff00 is the objc runtime page.  Someone (CFDictionaryAddValue) is sending messages to dealloced objects, most likely -NSMutableDictionary setValue:forKey:.  The dictionary is entirely internal to the Carbon MenuManager.  Since this is happening with MenuSelect down below, the only thing that could really be causing this (aside from OS bugs) is unclean menu destruction order.

I know that our menu destruction model in Carbon widgets is sucky, especially around hierarchial menus.  Maybe that's what's causing this.  I don't think this is Java-related, because I don't think JEP messes with the menus.

Comment 19

[chris hofmann]

josh, have you been able to look at this at all?

Comment 20

[semper]

For me, this always involves Java, though the relationship is not clear.

Steps to reproduce:

1. Java enabled, go to http://direktbank.at/.
2. Make a sub-menu of the "Bookmarks" menu fly out.
3. Move the mouse away to close the sub-menu again.
4. Select something else from the menu, say "Manage Bookmarks...".

Comment 21

[Uri Bernstein]

Thanks, [e-mail]!

I can reproduce consistently using the steps in comment #20, so I found the regression date (on trunk): between 2005-10-23 and 2005-10-24. This indicates that the culprit is bug 313510 (JEP v. 0.9.5).

Comment 22

[Steven Michaud [:smichaud] (Retired)]

Attachment: Crash in Firefox 1.5.0.4, with JEP 0.9.5+e, on OS X 10.4.6

I can only reproduce this crash on OS X Tiger, and I suspect it's due to one
or more bugs in Firefox and/or Tiger (or its JVMs).  But it does seem to be
triggered by a very obscure bug in the Java Embedding Plugin -- a flaw in a
fix for a different problem that was introduced in JEP 0.9.5.

By lucky chance, this is a bug I've already fixed in my current version of the
JEP (which will become version 0.9.5+f), a variant of which has already been
reported (I describe it at bug 341234 comment #10).

You can see the effects of this bug itself (without the crash) by following
the steps from comment #20 on OS X 10.3 in any Carbon-based Firefox browser,
with any Java applet.  The bug is that the first time you click on "Manage
Bookmarks...", nothing appears to happen (the Manage Bookmarks window only
comes up the second time you click).  Under the hood, though, the browser
window is very quickly being made inactive and then active again.

Comment 23

[Steven Michaud [:smichaud] (Retired)]

I've just released a new version (0.9.5+f) of the Java Embedding
Plugin that fixes this bug (at least insofar as it's described in
comment #22):

http://javaplugin.sourceforge.net/

Please follow the Readme's instructions to install the new JEP to your
/Library/Internet Plug-Ins/ folder, and to remove older copy(ies) of
the JEP from your Mozilla.org browser(s).

Comment 24

[Amos Hayes]

Tested with MOZILLA_1_8_0_BRANCH from CVS this afternoon:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.5) Gecko/20060706 Firefox/1.5.0.5

This has the new JEP (0.9.5+f) and I have no problems with the steps in comment #20.

Comment 25

[chris hofmann]

ok,  should we close this bug out, and maybe release note with a pointer to the latest JEP?

Comment 26

[Steven Michaud [:smichaud] (Retired)]

As you can see at bug 343180, the latest JEP (0.9.5+f) is now landed
on the trunk, the 1.8 branch and the 1.8.0 branch (or perhaps only the
1.8.0.5 branch).

But, though the crash reported here (at bug 320998) can be triggered
by a bug in the JEP (described in comment #22, and fixed by JEP
0.9.5+f), I suspect the crash is really a separate issue.

How about waiting for a few weeks, to see if the crash reported here
keeps happening with Firefox 1.5.0.5?  I expect that its frequency
will be much reduced.  If this crash is _never_ reported on Firefox
1.5.0.5, I suspect we should mark this bug FIXED.  But otherwise we
should probably just remove its "topcrash" keyword and leave it open.

Comment 27

[Steven Michaud [:smichaud] (Retired)]

> (or perhaps only the 1.8.0.5 branch)

It's on the 1.8.0 branch.  I just checked today's 1.8.0 branch
nightly, and Amos also indicates this in comment #24.

Comment 28

[Daniel Veditz [:dveditz]]

Too late for 1.8.0.5 if the new JEP 0.9.5+f from bug 343180 doesn't fix it, but sounds like it does.

Since this bug is based on talkback frequency the known-fixed scenario in comment 22 might not be the only trigger. Let's leave the bug open until we get some data back from the 1.5.0.5 release and see how it does.

Comment 29

[Daniel Veditz [:dveditz]]

Appears fixed by the new JEP, no longer appearing in the topcrash list for Macs