User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:126.96.36.199) Gecko/2009021906 Firefox/3.0.7 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:188.8.131.52) Gecko/2009021906 Firefox/3.0.7 Whenever I visit news.google.com with Mac OS X 10.4 (Intel) in Firefox 3.0.7, Shiretoko (3.1b4), or MinefieldDebug (3.2a1pre), the application crashes. In 3.0.7 and 3.1b4 it crashes immediately. In 3.2a1pre the spinning color wheel spins for a while, then it crashes. This does not happen in 3.0.7 on Mac OS X (PPC) or 3.0.7 on Windows Vista. Also does not happen in Safari 3.2.1 (Mac OS X Intel). After filing this I will attach a web archive of the page, which demonstrates the crash. Reproducible: Always Steps to Reproduce: 1. Load the attached web archive 2. Watch firefox fly into the bit bucket 3. Actual Results: Firefox crashes Expected Results: Firefox displays Google News.
Created attachment 366182 [details] Unzip to see a saved page of google news. Load this page to cause crash.
I'm not sure if this is relevant to this bug, but ATSUGetGlyphInfo() has been marked as deprecated: http://developer.apple.com/documentation/Carbon/Reference/ATSUI_Reference/DeprecationAppendix/AppendixADeprecatedAPI.html#//apple_ref/doc/uid/TP30000309-CH1g-F15046
Here is a 3.1b4 crash report stack trace: http://crash-stats.mozilla.com/report/index/48aaa11c-2682-45f8-93c9-4262f2090308 Here is a 3.0.7 (Safe Mode) stack trace: http://crash-stats.mozilla.com/report/index/efd78553-f0b8-4c03-95f7-a00482090308?p=1
ATSUGetGlyphInfo()'s deprecation is probably not relevant to this particular bug since when it crashes, aGlyphID is NULL, so the section of code in which it would be called is not executed. Also, it crashes before reaching that if statement in ATSUGetGlyphBounds().
Component: General → GFX: Thebes
Product: Firefox → Core
QA Contact: general → thebes
Please try disabling all non-Apple fonts you have installed (in /Library/Fonts and/or ~/Library/Fonts), and see if the crash persists. This problem is likely being triggered by a particular font that's present on your machine.
Michael, I set up a special build with logging around the point of failure. If it's not too much trouble, could you download this build to your Desktop and run through the steps below? http://tinyurl.com/logcharwidth Steps to log the error: 1. Run Terminal application 2. Enter these commands: cd ~/Desktop/Minefield.app/Contents/MacOS/ export NSPR_LOG_FILE=~/Desktop/funkyfont.out export NSPR_LOG_MODULES=charwidth:5 ./firefox 3. After Firefox starts, run the testcase that crashes 4. Attach the log file 'funkyfont.out', located on the desktop This will dump information about which font is causing the crash. The last line in the file should identify the name of the problematic font.
Thank you very much your help. With the special build from comment 8, I found out that it was the "Song" font installed in my /Library/Fonts folder. Using the validate feature in Font Book shows that there is a problem with the PostScript Compatibility Table. And if I disable it then Google News works fine. So it must have been a corrupt font after all. I'll mark this bug as invalid since it wasn't a problem with Firefox after all. Thanks again for your help everybody!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
Thanks for letting us know. Is the "Song" font involved one that's freely available somewhere? I'd be curious to see what kind of problem in the font was leading to the crash.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Sorry for the bugspam. Reopening because we should be catching these errors if possible and not crashing.
Assignee: nobody → jdaggett
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Summary: Google News crashes Firefox on Mac OS 10.4 Intel → corrupt font crashes Firefox on Mac OS 10.4 Intel
(In reply to comment #10) > Thanks for letting us know. Is the "Song" font involved one that's freely > available somewhere? I'd be curious to see what kind of problem in the font was > leading to the crash. Song came pre-installed with 10.3.x (and older maybe). I have it on an old G4 /10.3.9 http://support.apple.com/kb/HT1538 doesn't list it for 10.4 (but it could have been installed through migration assistant). (If you want the font to test, email me).
If the cause is indeed Song, then this testcase should induce the crash: http://tinyurl.com/badsong However, using Philippe's copy of the font I was unable to induce a crash on 10.4.11 or 10.5.6. Philippe's version of Song is 4.1d1e1 (FontBook, Preview > Show Font Info). Stepping through in the debugger, no error occurs while reading in the metrics. Michael, what's the version of Song you have? Also, could you attach the logfile described in comment 8? I just want to confirm that the description of the font.
(In reply to comment #12) > Song came pre-installed with 10.3.x (and older maybe). I have it on an old G4 > /10.3.9 > > http://support.apple.com/kb/HT1538 doesn't list it for 10.4 (but it could have > been installed through migration assistant). Yeah, it vanished from new installs starting with 10.4; it used to be a default Moz font, but we had to sub it out back in bug 299222 because it was missing on 10.4. I ran the copy from my 10.3 Mac (also 4.1d1e1) through Font Book on 10.5.6, and it does find a "minor" problem ("Warnings") with the "'post' table usability" in Song Regular.
Summary: corrupt font crashes Firefox on Mac OS 10.4 Intel → corrupt font crashes Firefox [@ ApplyMorphForRun][@ gfxAtsuiFont::GetCharWidth] on Mac OS 10.4 Intel
Mac 10.5 example from FF4.0.1 (bogus stack?) d16a7ad7-5232-4f93-a892-152c42110323
Crash Signature: [@ ApplyMorphForRun] [@ gfxAtsuiFont::GetCharWidth]
Closing for a couple reasons: 1) gfxAtsuiFont is no longer used, so either its not a problem or we need new crash bugs for it with different signatures 2) It was the Song font, in which case its gone on our supported platforms and not worth caring about.
Crash Signature: [@ ApplyMorphForRun] [@ gfxAtsuiFont::GetCharWidth] → [@ ApplyMorphForRun] [@ gfxAtsuiFont::GetCharWidth]
Status: NEW → RESOLVED
Last Resolved: 9 years ago → 7 years ago
Resolution: --- → INVALID
Technically I think this is WORKSFORME since the bug report was valid but no longer causes a problem (and we don't know exactly why).
Resolution: INVALID → WORKSFORME
You need to log in before you can comment on or make changes to this bug.