458645 - Firefox 3.0.* crash on startup with Mac OSX 10.4 PPC [@ HashString(nsAString_internal const&) ] - [@ GetOrMakeFont] - [@ gfxAtsuiFontGroup::InitFontList]

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect)

Description

[Daniel Stiner]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.3) Gecko/2008092515 Ubuntu/8.10 (intrepid) Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3

Firefox will sometimes refuse to open, throwing a very odd error.
Only a restart of the computer will allow it to open up again.

Reproducible: Sometimes

Steps to Reproduce:
1. Install Firefox 3 
2. Double-click on Firefox.app

Actual Results:  
NSometimes Firefox will refuse to start, opening an error report dialog.
This will continue every time Firefox is started, until the computer itself is restarted.
Also, running /Applications/Firefox.app/Contents/MacOS/firefox-bin in a terminal outputs the following:
Library-eMac-2:~ admin$ /Applications/Firefox.app/Contents/MacOS/firefox
2008-09-28 19:11:46.622 firefox-bin[824] Mozilla has caught an Obj-C exception [NSInvalidArgument Exception: *** -[NSCFDictionary setObject:forKey:]: attempt to insert nil value]


Only happens on a PPC Mac, Intel based Macs have not had a problem.
Firefox is usually be running off of a AFP share, but the problem still exists in local accounts.
Things look great and work well with 3.0.* on our School's Intel Macs, but our high number of PPC eMacs with this issue has forced our school to migrate to Safari. I would suspect other schools have had similar issues with their macs.

Comment 1

[Tyler Downer [He/Him]]

Please start in Safe Mode, with a New Profile, and read http://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report.

Comment 2

[Wayne Mery (:wsmwk)]

Daniel, do you still see this problem? And if so, are you able to get the information metioned in comment 1?

Comment 3

[Daniel Stiner]

Thanks for checking back on this bug, I have been too busy to worry about this (a downgrade to Firefox 2.0.06 fixed things)

I will try this month to do some clean starts and get some stack-traces on here for examination if the still exists.

Comment 4

[Tyler Downer [He/Him]]

Why are you using 2.0.0.6? Does this happen in 2.0.0.21?

Comment 5

[Daniel Stiner]

Sorry for the confusion, at the time I downgraded to 2.0.0.6, they now are back up to 2.0.0.21 or so, still with no issues.

Tomorrow I may be able to take some time to test and post stack-traces if this issue still exists in the latest 3 release.

Again, sorry to confuse, but thanks for checking back with me.

Comment 6

[Daniel Stiner]

I fired up a test on three different ppc eMacs and none of them showed any problems with FF 3.0.8

Not conclusive proof, I'll have to do some more testing (possibly in about two weeks after semester tests are over and things quiet down) but for right now, this bug is *likely* fixed.

Thanks a lot for checking back on this, hopefully all is good now.

Comment 7

[Tyler Downer [He/Him]]

WFM until further notice.

Comment 8

[Daniel Stiner]

Okay, so I have a few stack traces from 3.0.8 that *should* be related to this issue. I hope...  I could also generate some more for 3.0.09 if need be.

Crash ID: bp-1e57967a-30a2-41d5-b252-ee9972090428
Crash ID: bp-a5e542a7-5535-4b48-9e1a-74af52090428

Also some console stuff when I attempted to start the profile manager from the command line:
Welcome to Darwin!
Welcome to Darwin!
$ /Applications/Firefox.app/Contents/MacOS/firefox -ProfileManager
/Applications/Firefox.app/Contents/MacOS/run-mozilla.sh: line 442:   632 Bus error               "$prog" ${1+"$@"}
$ /Applications/Firefox.app/Contents/MacOS/firefox02-Media-Center-eMac:~ dstiner$ 2009-04-28 14:49:44.453 crashreporter[651] CFLog (0): CFMessagePort: bootstrap_register(): failed 1103 (0x44f), port = 0x3203, name = 'org.mozilla.crashreporter.ServiceProvider'
See /usr/include/servers/bootstrap_defs.h for the error codes.
2009-04-28 14:49:44.488 crashreporter[651] CFLog (99): CFMessagePortCreateLocal(): failed to name Mach port (org.mozilla.crashreporter.ServiceProvider)


I also am re-opening this bug until someone can decipher my stack traces.

Comment 9

[Wayne Mery (:wsmwk)]

stack sig HashString(nsAString_internal const&)
many of these on crash-stats are on startup http://crash-stats.mozilla.com/report/list?product=Firefox&branch=1.9.1&query_search=signature&query_type=contains&query=HashString&date=&range_value=4&range_unit=days&do_query=1&signature=HashString%28nsAString_internal%20const%26%29


bp-a5e542a7-5535-4b48-9e1a-74af52090428

0	XUL	HashString	nsTHashtable.cpp:43
1	XUL	PL_DHashTableOperate	pldhash.c:588
2	XUL	gfxFontCache::Lookup	mozilla/gfx/thebes/src/gfxFont.cpp:164
3	XUL	GetOrMakeFont	mozilla/gfx/thebes/src/gfxAtsuiFonts.cpp:447
4	XUL	gfxAtsuiFontGroup::gfxAtsuiFontGroup	mozilla/gfx/thebes/src/gfxAtsuiFonts.cpp:487
5	XUL	gfxPlatformMac::CreateFontGroup	mozilla/gfx/thebes/src/gfxPlatformMac.cpp:196
6	XUL	nsThebesFontMetrics::Init	mozilla/gfx/src/thebes/nsThebesFontMetrics.cpp:89
7	XUL	nsFontCache::GetMetricsFor	mozilla/gfx/src/nsDeviceContext.cpp:500
8	XUL	nsTextBoxFrame::GetTextSize	mozilla/layout/xul/base/src/nsTextBoxFrame.cpp:908
9	XUL	nsTextBoxFrame::CalcTextSize	mozilla/layout/xul/base/src/nsTextBoxFrame.cpp:926
10	XUL	nsTextBoxFrame::GetBoxAscent	mozilla/layout/xul/base/src/nsTextBoxFrame.cpp:974
11	XUL	nsSprocketLayout::GetAscent	mozilla/layout/xul/base/src/nsSprocketLayout.cpp:1525
12	XUL	nsBoxFrame::GetBoxAscent	mozilla/layout/xul/base/src/nsBoxFrame.cpp:844

Comment 10

[Daniel Stiner]

I apologize, I had not even glanced at the actual stack traces till just now. It defiantly seems like a problem with the HashString function.

Remember though this is not on 3.1x but on the older 3.0.x branch, and is only evidenced on ppc processors. Any Intel x86 Macs run Firefox just fine.

This may not even be the original problem, as it only occurred when profiles were located on an AFP share. This problem is evident even on a local account I think.
I have additional stack traces from an earlier Firefox build (3.0.3), but its possible the original bug has been fixed just to regress with this different, unrelated bug. I am going to mark this bug as worksforme for the next two weeks until have I time to separate out these bugs and test some of the new 3.1x builds.
Till then, thanks for being patient, hopefully this is not for naught and these are a couple of simple bugs to fix :)

Comment 11

[Arie Paap [:wildmyron]]

This crash is showing up in crash-stats, see http://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A3.5.3&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=startswith&query=HashString&do_query=1

Most crashes seem to be at startup and the stack is similar to comment 9

Example: bp-d2e07ded-d429-42e9-b6b6-7161c2090915

This doesn't seem to be restricted to MacOS 10.4 nor to PPC.

Reopen or new bug to track this issue?

Comment 12

[Josh Aas]

Reopening this bug - this is our #16 in reported Mac crash bugs. It exists, it is getting reported by PPC and x86 users.

Comment 13

[Wayne Mery (:wsmwk)]

#2 Mac crash in TB3.0.4, #44 crash overall for 3.0.4. about 80% are startup

the windows crashes don't have same stack, but are only 3% of the total crashes. for example 
bp-c419bf81-1bb9-46f5-91d5-a3ab72100613
bp-d9498f29-bed5-46d9-911b-8284b2100610

perhaps a skiplist for HashString(nsAString_internal const&)  is warranted?

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #13)
> #2 Mac crash in TB3.0.4, #44 crash overall for 3.0.4. about 80% are startup
> 
> the windows crashes don't have same stack, but are only 3% of the total
> crashes. for example 

Bug 552293 seems to be the bug on the Windows version.

Comment 15

[Wayne Mery (:wsmwk)]

not sure what changed since , but this is far from being a topcrash in 3.1.7. And the stats indicate that currently, it happens more in 3.0.x builds than 3.1.x, despite 3.0.x having fewer users

removing [tb31wants] and [tb30wants]

Comment 16

[Scoobidiver (away)]

The topcrash- keyword is not actively maintained and pollutes queries with topcrash.

Comment 17

[Jonathan Kew [:jfkthame]]

Moreover, the code in question no longer exists in any currently-maintained version, and hasn't for quite a while now. (We removed the ATSUI rendering code in bug 548177.) I think we should just close this - I'd choose "RESOLVED: OBSOLETE" if we had such a setting, but failing that, it looks INCOMPLETE.

(My guess is that this may have been associated with damaged font files or caches, but it doesn't look like we ever had a reproducible testcase or anything.)