489948 - Loading standblog.org crashes [@ libobjc.A.dylib@0x15688 - ATS@0x18284 ][@ gfxAtsuiFont::GetCharWidth]

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Ludovic Hirlimann [:Usul]]

bp-39baae29-a781-402f-a041-bb6e32090423
bp-82411181-6d13-4ab8-8b37-bee402090423

0  	libobjc.A.dylib  	libobjc.A.dylib@0x1568c  	
1 	ATS 	ATS@0x18284 	
2 	QD 	QD@0x81ce 	
3 	QD 	QD@0x1e0e8 	
4 	QD 	QD@0x1debc 	
5 	QD 	QD@0x1d612 	
6 	QD 	QD@0x2f28e 	
7 	QD 	QD@0x39e98 	
8 	QD 	QD@0x39dc9 	
9 	XUL 	gfxAtsuiFont::GetCharWidth 	mozilla/gfx/thebes/src/gfxAtsuiFonts.cpp:330
10 	XUL 	gfxAtsuiFont::InitMetrics 	mozilla/gfx/thebes/src/gfxAtsuiFonts.cpp:282
11 	XUL 	gfxAtsuiFont::gfxAtsuiFont 	mozilla/gfx/thebes/src/gfxAtsuiFonts.cpp:117
12 	XUL 	GetOrMakeFont 	mozilla/gfx/thebes/src/gfxAtsuiFonts.cpp:449
13 	XUL 	gfxAtsuiFontGroup::FindATSUFont 	mozilla/gfx/thebes/src/gfxAtsuiFonts.cpp:523
14 	XUL 	gfxFontGroup::FontResolverProc 	mozilla/gfx/thebes/src/gfxFont.cpp:919
15 	XUL 	gfxPlatformMac::ResolveFontName 	mozilla/gfx/thebes/src/gfxPlatformMac.cpp:181
16 	XUL 	gfxFontGroup::ForEachFontInternal 	mozilla/gfx/thebes/src/gfxFont.cpp:886
17 	XUL 	gfxFontGroup::ForEachFont 	mozilla/gfx/thebes/src/gfxFont.cpp:762
18 	XUL 	gfxAtsuiFontGroup::gfxAtsuiFontGroup 	mozilla/gfx/thebes/src/gfxAtsuiFonts.cpp:468
19 	XUL 	gfxPlatformMac::CreateFontGroup 	mozilla/gfx/thebes/src/gfxPlatformMac.cpp:196
20 	XUL 	nsThebesFontMetrics::Init 	mozilla/gfx/src/thebes/nsThebesFontMetrics.cpp:89
21 	XUL 	nsFontCache::GetMetricsFor 	mozilla/gfx/src/nsDeviceContext.cpp:500
22 	XUL 	nsLayoutUtils::GetFontMetricsForStyleContext 	mozilla/layout/base/nsLayoutUtils.cpp:1304
23 	XUL 	nsHTMLReflowState::CalcLineHeight 	mozilla/layout/generic/nsHTMLReflowState.cpp:2052
24 	XUL 	nsBlockReflowState::nsBlockReflowState 	mozilla/layout/generic/nsBlockReflowState.cpp:428
25 	XUL 	nsBlockFrame::Reflow 	mozilla/layout/generic/nsBlockFrame.cpp:927
26 	XUL 	nsContainerFrame::ReflowChild 	mozilla/layout/generic/nsContainerFrame.cpp:775
27 	XUL 	CanvasFrame::Reflow 	mozilla/layout/generic/nsHTMLFrame.cpp:584
28 	XUL 	nsContainerFrame::ReflowChild 	mozilla/layout/generic/nsContainerFrame.cpp:775
29 	XUL 	nsHTMLScrollFrame::ReflowScrolledFrame 	mozilla/layout/generic/nsGfxScrollFrame.cpp:499
30 	XUL 	nsHTMLScrollFrame::ReflowContents 	mozilla/layout/generic/nsGfxScrollFrame.cpp:593
31 	XUL 	nsHTMLScrollFrame::Reflow 	mozilla/layout/generic/nsGfxScrollFrame.cpp:794
32 	XUL 	nsContainerFrame::ReflowChild 	mozilla/layout/generic/nsContainerFrame.cpp:775
33 	XUL 	ViewportFrame::Reflow 	mozilla/layout/generic/nsViewportFrame.cpp:285
34 	XUL 	PresShell::DoReflow 	mozilla/layout/base/nsPresShell.cpp:6222
35 	XUL 	PresShell::ProcessReflowCommands 	mozilla/layout/base/nsPresShell.cpp:6328
36 	XUL 	PresShell::DoFlushPendingNotifications 	mozilla/layout/base/nsPresShell.cpp:4534
37 	XUL 	PresShell::ReflowEvent::Run 	mozilla/layout/base/nsPresShell.cpp:6111
38 	XUL 	nsThread::ProcessNextEvent 	mozilla/xpcom/threads/nsThread.cpp:510
39 	XUL 	NS_ProcessPendingEvents_P 	nsThreadUtils.cpp:180
40 	XUL 	nsBaseAppShell::NativeEventCallback 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:121
41 	XUL 	nsAppShell::ProcessGeckoEvents 	mozilla/widget/src/cocoa/nsAppShell.mm:309
42 	CoreFoundation 	CoreFoundation@0x735f4 	
43 	CoreFoundation 	CoreFoundation@0x73cd7 	
44 	HIToolbox 	HIToolbox@0x302bf 	
45 	HIToolbox 	HIToolbox@0x30011 	
46 	HIToolbox 	HIToolbox@0x2ff4c 	
47 	AppKit 	AppKit@0x40d7c 	
48 	AppKit 	AppKit@0x4062f 	
49 	AppKit 	AppKit@0x3966a 	
50 	XUL 	nsAppShell::Run 	mozilla/widget/src/cocoa/nsAppShell.mm:598
51 	XUL 	nsAppStartup::Run 	mozilla/toolkit/components/startup/src/nsAppStartup.cpp:181
52 	XUL 	XRE_main 	mozilla/toolkit/xre/nsAppRunner.cpp:3193
53 	firefox-bin 	main 	mozilla/browser/app/nsBrowserApp.cpp:158
54 	firefox-bin 	start 	crt.c:272
55 	firefox-bin 	start 	
56 		@0x1

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.9) Gecko/2009040820 Firefox/3.0.9.

I wanted to save the page to attach it here but : 
Work:Testcases ludo$ curl -O http://standblog.org
curl: Remote file name has no length!
curl: try 'curl --help' or 'curl --manual' for more information

Comment 1

[Kurt Weinschenker]

Ludovic,

Tried this with a recent 2.0b3pre build of Camino (1.9.0.10pre 2009042406) running under PPC-Tiger; no crash.

Possibly Intel or 10.5-specific?

Comment 2

[Ludovic Hirlimann [:Usul]]

(In reply to comment #1)
> Possibly Intel or 10.5-specific?

Maybe . I don't have a PPC machine handy.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

WFM on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 - I'm getting 3.0.9 now.

Also, standblog.org apparently redirects to http://standblog.org/blog/ that's probably why you can't curl it, and we should probably also get Tristan Nitot here since he's the author of that blog, esp if the crash is reproducible. :)

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

WFM on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.9) Gecko/2009040820 Firefox/3.0.9 with a fresh profile. (Same build as you)

Try with a fresh profile?

Comment 5

[Ludovic Hirlimann [:Usul]]

No did not.

Comment 6

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

See also bug 479771, bug 459531, and bug 459711.

Ludo, the first thing you should do is check for duplicate fonts and validate all your fonts in Font Book.

If you don't find any smoking guns there, we'll have to hook you up with a font logging build (if you can reproduce the crash reliably).

Comment 7

[Ludovic Hirlimann [:Usul]]

(In reply to comment #6)
> See also bug 479771, bug 459531, and bug 459711.
> 
> Ludo, the first thing you should do is check for duplicate fonts and validate
> all your fonts in Font Book.

They all validate.
 
> If you don't find any smoking guns there, we'll have to hook you up with a font
> logging build (if you can reproduce the crash reliably).

It seems I still crash. Where can I find such a build of firefox ?

Comment 8

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

(In reply to comment #7)
> > If you don't find any smoking guns there, we'll have to hook you up with a font
> > logging build (if you can reproduce the crash reliably).
> 
> It seems I still crash. Where can I find such a build of firefox ?

It looks like all of the older try-server builds have aged out; John, can you make a new one for Ludo to try here?

Comment 9

[Ludovic Hirlimann [:Usul]]

Hum I also crash on http://www.figuiere.net/hub/blog/, which runs the same software than standblog.org.

Comment 10

[John Daggett (:jtd)]

Attachment: patch, log calls to GetCharWidth

patch to log calls to InitMetrics and GetCharWidth with fontname/size info, along with text runs and font matching.

Running a try server build now.

Comment 11

[Ludovic Hirlimann [:Usul]]

Where Can I find the build ?

Comment 12

[John Daggett (:jtd)]

A try server build is available here:

http://tinyurl.com/getcharwidthlogging

It will be available for two weeks.

To log detailed font information, please use these steps:

1. Download the build and copy the Minefield app to the Desktop
2. Quit Firefox if running already
3. Open Terminal and execute these commands:

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

4. Run through tests that cause a crash
5. In the Terminal window, copy the logfile to the Desktop

  cp fontinfo.out ~/Desktop

6. Attach the logfile to this bug (zip if >300K)

You should be able to identify the problem font by looking at the last few lines
outputted to the logfile:

  tail -10 fontinfo.out

Comment 13

[Ludovic Hirlimann [:Usul]]

 Now that I have a debug build I can't make Ff crash reliably anymore :-(. I've been trying with my ff and the debug build for the last 30 minutes.

Comment 14

[Ludovic Hirlimann [:Usul]]

Got that on the console while I had the same crash today :
Work:MacOS ludo$ Debugger() was called!
Debugger() was called!
Debugger() was called!
Mon May  4 15:02:20 Work.local firefox-bin[44141] <Error>: GCGetStrikeMetrics failed: error 4.
firefox-bin(44141,0xa070f720) malloc: *** error for object 0x23026e00: non-page-aligned, non-allocated pointer being freed
*** set a breakpoint in malloc_error_break to debug
firefox-bin(44141,0xa070f720) malloc: *** error for object 0x171aef10: Non-aligned pointer being freed (2)
*** set a breakpoint in malloc_error_break to debug


Will run with the debug version longer.

Comment 15

[Ludovic Hirlimann [:Usul]]

(In reply to comment #14)
> Mon May  4 15:02:20 Work.local firefox-bin[44141] <Error>: GCGetStrikeMetrics
> failed: error 4.

Based on this error here is what minefield debug gives :
-1603209440[40aac0]: InitTextRun 16c313b0 fontgroup 16b7fc70 font 16b7fcd0 match Helvetica (0-8)
-1603209440[40aac0]: InitTextRun 16c31480 fontgroup 16b7fc70 ("Bitstream Vera Sans",sans-serif,serif) lang: x-western len 4 TEXTRUN "atom" ENDTEXTRUN
-1603209440[40aac0]: InitTextRun 16c31480 fontgroup 16b7fc70 font 16b7fcd0 match Helvetica (0-4)
-1603209440[40aac0]: initmetrics Bad font metrics for: BitstreamVeraSans-Roman err: 00000004-1603209440[40aac0]: initmetrics font: 16c31770 (Helvetica) size: 9.600000
-1603209440[40aac0]: getcharwidth font: Helvetica glyph: 0078
-1603209440[40aac0]: getcharwidth font: Helvetica glyph: 0020-1603209440[40aac0]: getcharwidth font: Helvetica glyph: 0030
-1603209440[40aac0]: initmetrics font: 16c31770 (Helvetica) done
-1603209440[40aac0]: initmetrics font: 16c31b80 (Times-Roman) size: 9.600000-1603209440[40aac0]: getcharwidth font: Times-Roman glyph: 0078
-1603209440[40aac0]: getcharwidth font: Times-Roman glyph: 0020
-1603209440[40aac0]: getcharwidth font: Times-Roman glyph: 0030-1603209440[40aac0]: initmetrics font: 16c31b80 (Times-Roman) done


I can attach the complete log. I can really easily crash the 3.0.10 version of FF, while I have been unable to reproduce for minefield. Would getting a debug version of ff make more sense ?

Comment 16

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

> -1603209440[40aac0]: initmetrics Bad font metrics for: BitstreamVeraSans-Roman
> err: 00000004

Looks like Bitstream Vera Sans Roman is probably your culprit.  What version of it do you have?  (And what is it with these open-source fonts? :P )

Comment 17

[Ludovic Hirlimann [:Usul]]

(In reply to comment #16)
> > -1603209440[40aac0]: initmetrics Bad font metrics for: BitstreamVeraSans-Roman
> > err: 00000004
> 
> Looks like Bitstream Vera Sans Roman is probably your culprit.  What version of
> it do you have?  (And what is it with these open-source fonts? :P )
Work:~ ludo$ port list |grep bitstream
bitstream-vera                 @1.10           graphics/bitstream-vera

This seems to be the only vera font that I could find. Font Book does not show it.

Comment 18

[timeless]

free fonts (open source or not) have a tendency to be really ****.

i've been dealing w/ bad fonts for 16+ years. be thankful that the fonts you're seeing in *general* aren't causing BSODs or an equivalent.

Comment 19

[John Daggett (:jtd)]

Attachment: patch, backport fix for 476504 to 1.9.0

This appears to be the same problem as in bug 476504, except in this case a crash occurs.

Comment 20

[John Daggett (:jtd)]

I ran a try server build with the patch from bug 476504 on top of cvs trunk code (== Firefox 3.0.10).

Ludovic, could you test this build to verify that it eliminates the crash that you were seeing?

http://tinyurl.com/handlemetricserr

Comment 21

[Ludovic Hirlimann [:Usul]]

(In reply to comment #20)
> I ran a try server build with the patch from bug 476504 on top of cvs trunk
> code (== Firefox 3.0.10).
> 
> Ludovic, could you test this build to verify that it eliminates the crash that
> you were seeing?

It does indeed.

Comment 22

[John Daggett (:jtd)]

Comment on attachment 375950 [details] [diff] [review]
patch, backport fix for 476504 to 1.9.0

Requesting approval for the next 1.9.0.x release.  This code has been tested on 1.9.x trunk for several months now and was included in 3.5b3.  The person reporting the bug verified that it fixes the crash he was hitting.

Comment 23

[Samuel Sidler (old account; do not CC)]

Comment on attachment 375950 [details] [diff] [review]
patch, backport fix for 476504 to 1.9.0

Moving this out to 1.9.0.12 since we've code frozen.

Comment 24

[Daniel Veditz [:dveditz]]

Comment on attachment 375950 [details] [diff] [review]
patch, backport fix for 476504 to 1.9.0

Approved for 1.9.0.12, a=dveditz for release-drivers

Comment 25

[Daniel Veditz [:dveditz]]

Please get a testcase captured in this bug so QA can verify the fix without having to worry about the site changing.

Comment 26

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

John, is this waiting on anything before landing?

Comment 27

[John Daggett (:jtd)]

Attachment: problematic version of Terminus font

It's hard to reproduce the crash, but console errors indicate when the problem is occurring.

Testcase:

1. Open Console app (Finder > Go > Utilities)
2. Install attached version of Terminus font into ~/Library/Fonts
3. Run Firefox
4. Enter data:text/html,<html><body style="font-family: Terminus;"><strong>This is </strong>a test</body></html>

Result: if a crash doesn't occur, page doesn't render and errors show up in the console:

<Error>: GCGetStrikeMetrics failed: error 3. 

Note: font is licensed under GNU GPL 2.0, see page below for details:

http://fractal.csie.org/~eric/wiki/Terminus_font

With the fixed version page is rendered and no console errors occur.

Comment 28

[John Daggett (:jtd)]

Checked in to CVS trunk.
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/gfx/thebes/src&command=DIFF_FRAMESET&root=/cvsroot&file=gfxAtsuiFonts.cpp&rev1=1.100&rev2=1.101

Comment 29

[Samuel Sidler (old account; do not CC)]

John: Just to confirm, this is 1.9.0-only, right?

Comment 30

[Samuel Sidler (old account; do not CC)]

I'm going to assume yes and not block on this for 1.9.1.1 which will have the same security and stability fixes as 1.9.0.12. John, please renom if that's wrong.

Comment 31

[John Daggett (:jtd)]

(In reply to comment #30)
> I'm going to assume yes and not block on this for 1.9.1.1 which will have the
> same security and stability fixes as 1.9.0.12. John, please renom if that's
> wrong.

No, this was fixed in trunk/1.9.1 as part of bug 476504 (comment 19).  So don't need 1.9.1.x flags.