463861 - Crash [@ FOGetNameInternal] (ReadOtherFamilyNamesForFace calls broken ATSUI code)

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P2)

Description

[Colin S]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.3) Gecko/2008092510 Ubuntu/8.04 (hardy) Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-GB; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3

At some point during browsing, usually when loading a new Web site, Firefox crashes, and then continues to crash over and over again until I either start a new session or manage to close all of the tabs from my previous session before the pages finish loading. Often the browser pinwheels for several seconds before the initial crash occurs.

Reproducible: Couldn't Reproduce

Steps to Reproduce:
1. A crash occurs
2. Report and restart the browser
3. Crash again
Actual Results:  
Crash

Expected Results:  
No crashing!

I have lots and lots of backtraces for this crash because it occurs pretty regularly, but not reproducibly. Here are some of the report IDs. They all crash in the same location.

137c8d3a-adfd-11dd-ab01-001a4bd43e5c
c9166ab0-ad64-11dd-b7ab-001a4bd43ed6
47dcf9a1-ad64-11dd-b31f-001cc45a2ce4
3c4c1e07-8efc-11dd-8fec-001a4bd43ef6
af5c2107-8cd2-11dd-b4a2-001cc45a2c28
fb67fef3-8b52-11dd-a702-001a4bd43e5c
521061ca-8a71-11dd-9c32-001cc45a2ce4

Also, since this is font related, I will mention that I have a greater-than-average number of fonts installed (1396) and some of the fonts have many variants (up to 30). I haven't overridden any of the browser font settings, however.

Comment 1

[Matthias Versen [:Matti]]

the crash is not from ReadOtherFamilyNamesForFace, that is only the last Gecko function. It looks like a OS font issue because the crash is deep in the OS librarys. Did you try to clear the os font cache, for example with this http://homepage.mac.com/mdouma46/fontfinagler/ ?


0  	 	@0xffff0996  	
1 	ATS 	ATS@0x3f2e 	
2 	ATS 	ATS@0x1667f 	
3 	ATS 	ATS@0x14a61 	
4 	ATS 	ATS@0x148cb 	
5 	QD 	QD@0x247a3 	
6 	QD 	QD@0x337ca 	
7 	XUL 	ReadOtherFamilyNamesForFace 	mozilla/gfx/thebes/src/gfxQuartzFontCache.mm:614
8 	XUL 	MacOSFamilyEntry::ReadOtherFamilyNames 	mozilla/gfx/thebes/src/gfxQuartzFontCache.mm:663
9 	XUL 	gfxQuartzFontCache::RunLoader 	mozilla/gfx/thebes/src/gfxQuartzFontCache.mm:1322
10 	XUL 	gfxFontInfoLoader::LoaderTimerCallback 	mozilla/gfx/cairo/libpixman/src/pixman-access-accessors.c:426
11 	XUL 	nsTimerImpl::Fire 	mozilla/xpcom/threads/nsTimerImpl.cpp:400
12 	XUL 	nsTimerEvent::Run 	mozilla/xpcom/threads/nsTimerImpl.cpp:490

Comment 2

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

You should also use Font Book to verify your fonts; this crash may be caused by corrupt fonts.

There are about 20 crashes (fx3.0.3) in just the past day that are likely this type of crash (a couple in that list have stacks that are different enough to be unlikely); I've added the more common Frame 0s to the summary.

Comment 3

[timeless]

http://www.afp548.com/article.php?story=20040802225219421

if firefox doesn't crash right away, use ktrace -p {pid-of firefox-bin}
(you can get the firefox pid from activitymonitor.app), otherwise you'd need to figure out how to run firefox from ktrace....

we can't use the output from ktrace, you're going to want to use kdump. if i'm right, the last couple of NAMIs that include 'Fonts' or 'ttf' should give a good hint as to which font is causing issues.

Comment 4

[Colin S]

Clearing the font cache did not resolve the problem. The only NAMI lines that include "Fonts" or "ttf" are:

NAMI  "/System/Library/Fonts/LucidaGrande.dfont"

There are only 5 of them,and they occur in the first 5% of the trace dump. [As an aside, if the dump files weren't over 30MB compressed, I'd attach them. If you have any specific grep you want me to run against the kdump for you, let me know.]

The latest reports are
2fe25863-af0c-11dd-8417-001a4bd43ed6
b7ec7851-af0c-11dd-8489-001cc45a2c28
974f0f4a-af0e-11dd-85e7-001a4bd43ef6

I can't get my head around this thing. Firefox was stuck in a looping crash (Crash -> Report & Restart -> Restore Session -> Crash, which is how I obtained the dump). After getting the ktrace of the crash, I told Crash Reporter to quit instead and ran firefox-bin (accidentally, without thinking about it) as root under ktrace and it loaded fine (but without my preferences or session). Then, I quit Firefox, and ran it again under my user account and restored the session and it suddenly wasn't crashing any more. (?!?!)

Comment 5

[timeless]

um, that's the *only* line that contains "Fonts"? strange. how about any lines that contain Fonts (again, favoring the end of the log) ... I'm not a ktrace expert :). fwiw it seems many files may be .otf instead of .ttf - http://support.apple.com/kb/HT1538

Comment 6

[Colin S]

Dump is 2144623 lines long. This is the end of a "grep -in 'fonts' DSTrace.txt":

2092967:        NSFontVisibleNameAttribute\0\0NSFontSizeAttribute\0NSFontFaceAttribute\0NSFontNameAttribute\0NSFontFamilyAttribute\0\0\0N\
2092975:        e bundle %@ can't be found.\0\0\0CCP__NPickColor\0CCP__FontPanelOpen\0\0CCP__FontPanelSelectFonts\0\0\0CCP__FontPanelClos\
2130131:        atch: ATSFontGetGlyphCount returned %d; FOCountGlyphs returned %zd.\0!CFSetContainsValue(fonts, a)\0\0\0ats-font.c\0\0%s:\
2137301:        \0browser.display.use_document_fonts\0\0intl.charset.default\0\0\0\0intl.accept_languages\0\0\0intl.accept_charsets\0\0\0\
2137311:        document_colors\0browser.use_document.fonts\0\0browser.link_expiration\0browser.startup.page\0\0\0\0general.always_load_i\
2137324:        WebKitDefaultTextEncodingName\0\0\0WebKitStandardFont\0\0font.name.serif.\0\0\0\0WebKitDefaultFontSize\0\0\0font.size.ser\
2137325:        if.\0\0\0\0WebKitFixedFont\0font.name.fixed.\0\0\0\0WebKitDefaultFixedFontSize\0\0font.size.fixed.\0\0\0\0WebKitMinimumFo\

There are 338 total matches, these are the only ones anywhere near the end of the trace.

Comment 7

[timeless]

ok. i give up. jdaggett: good luck :)

Comment 8

[John Daggett (:jtd)]

Colin, are you still seeing this problem?  If you are, I can set up a special logging version of FF so we can trace down to see if a specific font is causing this or if the problem is some underlying ATS issue that FF is somehow touching.

Comment 9

[Colin S]

Yes, I've had 20 more crashes since I last provided a report ID on this issue and would be most interested in getting to the bottom of it.

Comment 10

[John Daggett (:jtd)]

So the crash occurs sometimes but not consistently?  And when it does occur it happens at or near startup right?

I'm going to put together a build with more logging enabled so we can track this down.

Comment 11

[Colin S]

What generally happens is that through random browsing I will hit upon a condition where Firefox crashes, and then by restarting and restoring that previous session I can trigger the same crash over and over again until the session is erased (I've gotten the browser into an interesting half-crashed state before by hammering cmd+w to close all the reloading pages before it crashed completely, too). I've never been able to create a reproducible test case for the initial crash, but thankfully (?) it is completely repeatable once I get the browser into that inconsistent state.

Comment 12

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

(In reply to comment #11)
> case for the initial crash, but thankfully (?) it is completely repeatable once
> I get the browser into that inconsistent state.

If that happens again, you can hang on to your sessionstore.js file (move it out of your profile and to somewhere safe), and then you can use the file again when John gets a logging build ready; you won't have to surf around for pages that cause the crash.

Comment 13

[John Daggett (:jtd)]

Attachment: patch, enable logging of calls to ReadOtherFamilyNamesForFace

Enables font logging in production build and adds more logging within ReadOtherFamilyNamesForFace so we can determine the exact font that's causing this.

Running a try server build now, will post the URL when that completes.

Comment 14

[John Daggett (:jtd)]

A build of Firefox trunk (3.0.6pre) with logging enabled for the routine where the crash occurs can be found here:

  https://build.mozilla.org/tryserver-builds/2008-12-04_22:[e-mail]-readotherslogging/

To use this:

1. Download Mac build (.dmg) and copy to desktop
2. Open the archive and copy the application, Minefield.app, to your desktop
3. Quit Firefox
4. Open Terminal
5. Run Firefox using the following commands:

  cd Desktop/Minefield.app/Contents/MacOS/
  export NSPR_LOG_MODULES=fontInfoLog:5
  export NSPR_LOG_FILE=~/Desktop/fontinfo.out
  ./firefox

6. Run until Firefox crashes
7. Compress the logfile on your Desktop, fontinfo.out, and attach it to the bug

This will log all fonts found on your system when starting up.  You should be able to determine the problem font using these commands after a crash:

  cd Desktop
  tail -20 fontinfo.out

The font on the last line is most likely the font causing the problem.

Comment 15

[John Daggett (:jtd)]

Attachment: testcase, system font fallback test

This page contains a single non-defined Unicode character, which will force all fonts to be examined as part of system-wide font fallback.  This may cause the problem to occur, it may not.

Comment 16

[Colin S]

2008-12-07 03:09:03 -0600

EXC_BAD_ACCESS (0x0001)
KERN_INVALID_ADDRESS (0x0001) at 0x158f0643

Thread 0 Crashed:
0    __memcpy + 92 (cpu_capabilities.h:228)
1    MoveBytes + 31
2    FOGetNameInternal + 748
3    _eFOGetName + 386
4    FOGetName + 97
5    CopyFontName(privateFontObjectRecord*, unsigned long, unsigned long, unsigned long, char*) + 68
6    ATSUGetIndFontName + 203
7    gfxQuartzNativeDrawing::gfxQuartzNativeDrawing[not-in-charge](gfxContext*, gfxRect const&) + 7422
8    gfxQuartzNativeDrawing::gfxQuartzNativeDrawing[not-in-charge](gfxContext*, gfxRect const&) + 8431
9    gfxQuartzNativeDrawing::gfxQuartzNativeDrawing[not-in-charge](gfxContext*, gfxRect const&) + 6246

The crash occurs on this font:

-1610559488[6071b0]: (fontinit) family: Abaddon™, psname: Abaddon, face: don™, apple-weight: 5, css-weight: 4, traits: 0100000c
[...]
-1610559488[6071b0]: (fontinit-othernames) psname:Abaddon family:Abaddon™ nameCount:22
-1610559488[6071b0]: (fontinit-othernames) psname:Abaddon nameIndex:0

Comment 17

[John Daggett (:jtd)]

Ok, that's good information.  Could you open up FontBook and paste in the font information for your copy of Abaddon?  I found the font on MyFonts but I'm not seeing the problem on my machine.  The name looks different too, it doesn't appear to have the tm symbol in the family name, so you may have a previous version.

It would also be interesting to double-check if disabling the font in FontBook (Edit > Disable ..font..) causes the problem to go away.

Comment 18

[Colin S]

I disabled the font and hopefully that will see the end of this problem. I use Linotype FontExplorer X for font management and it is apparently a little lax on its font sanity checks. I ran FontBook's Font Validation on the file and it says that the Font Name Table is invalid; no surprise there, given where the crash occurred. It's rather strange that Firefox is the only software that was having problems, though, and that it was so intermittent; other software that I would expect to see fail (FontExplorer, Photoshop, OpenOffice.org, etc.) didn't. If you want a copy of a font with a corrupt font name table for testing, let me know and I can attach it. :)

Comment 19

[John Daggett (:jtd)]

(In reply to comment #18)
> I disabled the font and hopefully that will see the end of this problem. I use
> Linotype FontExplorer X for font management and it is apparently a little lax
> on its font sanity checks. I ran FontBook's Font Validation on the file and it
> says that the Font Name Table is invalid; no surprise there, given where the
> crash occurred. It's rather strange that Firefox is the only software that was
> having problems, though, and that it was so intermittent; other software that I
> would expect to see fail (FontExplorer, Photoshop, OpenOffice.org, etc.)
> didn't. If you want a copy of a font with a corrupt font name table for
> testing, let me know and I can attach it. :)

To be able to deal with internationalized font family names, Firefox reads through the name table using ATSUI API's.  We use this to build tables that are used for searching font data, normal apps simply rely on normal system API's.

My guess is that other apps don't delve into the font data this much, although I'm surprised FontExplorer X didn't catch these problems.

Comment 20

[Tanner M. Young [:tmyoung]]

Is this still an issue?  Should we change the status of the bug to Assigned?

Comment 21

[Jesse Ruderman]

jdaggett, have you figured out whether this is a Gecko bug or an ATSUI bug?  What still needs to happen here?

Comment 22

[John Daggett (:jtd)]

This is definitely an ATSUI bug in the code for reading a font's name table.  I still don't have a solid testcase for this, I can install and run with the font that caused the crash for the original reporter.  Usually the routine in question is only called a few seconds after startup, so the crash should happen fairly quickly in most cases.

Crash reports for this bug:
http://bit.ly/Z9smk

We could just dump the use of this ATSUI routine and use our own name reading routines, that might take care of the problem.  Trunk code does this:

http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/src/gfxFont.cpp#485

Comment 23

[Jesse Ruderman]

Yeah, I think we should.  Especially if @font-face can trigger this bug.

How hard is it to take just this change from the gigantic changeset 9d372f843f72 from bug 493280?

Comment 24

[John Daggett (:jtd)]

The function in question is never called on @font-face fonts, it's only used for platform fonts.  We need to look up platform fonts by the name defined in the font data, @font-face fonts are looked up using the name defined in the @font-face rule.  This is part of the problem reproducing it, it will only happen when there's some funky font on a user's system.

The portion of Jonathan's big changeset needed to eliminate the use of ATSUI for name lookup is fairly contained, I'll see if I can put together a patch for this.

Comment 25

[Daniel Veditz [:dveditz]]

A patch will be nice to have, but if it's not downloadable fonts then it doesn't need to block a particular release

Comment 26

[John Daggett (:jtd)]

Other crash reports:

FOFindTableIndexInternal, mostly 10.4.11
http://crash-stats.mozilla.com/report/list?product=Firefox&platform=mac&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=FOFindTableIndexInternal

0 ATS FOFindTableIndexInternal
1 ATS FOFindTableInCache
2 ATS FindOrSynthesizeTable
3 ATS _eFOCountNames
4 ATS FOCountNames
5 QD ATSUCountFontNames
6 XUL ReadOtherFamilyNamesForFace gfx/thebes/src/gfxQuartzFontCache.mm:565
7 XUL MacOSFamilyEntry::ReadOtherFamilyNames gfx/thebes/src/gfxQuartzFontCache.mm:628

_eFOGetName, occurs on 10.4, 10.5 and 10.6
http://crash-stats.mozilla.com/report/list?product=Firefox&platform=mac&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=_eFOGetName

0 @0xffff893c
1 ATS _eFOGetName
2 ATS FOGetName
3 QD CopyFontName
4 QD ATSUGetIndFontName
5 XUL ReadOtherFamilyNamesForFace gfx/thebes/src/gfxQuartzFontCache.mm:579
6 XUL MacOSFamilyEntry::ReadOtherFamilyNames gfx/thebes/src/gfxQuartzFontCache.mm:628
7 XUL gfxQuartzFontCache::InitOtherFamilyNamesProc gfx/thebes/src/gfxQuartzFontCache.mm:860
8 XUL PL_DHashTableEnumerate pldhash.c:735
9 XUL gfxQuartzFontCache::InitOtherFamilyNames nsBaseHashtable.h:221

Comment 27

[John Daggett (:jtd)]

This has been fixed by the work that Jonathan did to parse name tables directly.