180309 - Xft Crash while loading page with MS .fon font or read-protected font - FF10RC2 [@ GetNormalLineHeight]

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Didier Moens]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021114

Mozilla exits without warning (no additional dump info when launched from shell).


Reproducible: Always

Steps to Reproduce:




RedHat 8.0 GTK2 nightly build : mozilla-1.2b-2002111417_trunk_rh8_gtk2

Crashes with :
- the 20021024 build too (my first installed GTK2 one).

No crashes with :
- Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016


Could the crash be invoked by the CSS/JS of the menu on the index page ? I use
the very same menu on an intranet application, and the gtk2-build crashes too.

Comment 1

[Didier Moens]

The GTK2-build also crashes on http://www.brainjar.com/dhtml/menubar/ ; this is
the first page of the DHTML menu tutorial, and as such, only contains a subset
of the complete menu code.

Hence, the crash is probably invoked within this subset.

Comment 2

[Olivier Cahagne]

can you post Talkback ID for this crash
'mozilla/bin/components/talkback/talkback' or a stack trace with GDB ?

Comment 3

[Olivier Cahagne]

oops, I didn't read "Mozilla exits without warning (no additional dump info when
launched from shell)", sorry.

Comment 4

[Didier Moens]

WRT comment #2 :

Olivier, I'd love to include a talkback,  but :

1. talkback does not seem to be included in the gtk2 trunk rpm's ;
2. I wouldn't know where to look for the info to send along with the talkback
(on Win, this is automatically included) ;
3. not experienced with gdb stacktrace (but eager to learn).

3. Off-topic : I've always wanted to trace my Windows talkbacks, but don't have
the slightest idea where to look (Bugzilla topcrashes ? Somewhere else, probably ?).

Comment 5

[Andrew Schultz]

if you run mozilla from a terminal, does it print anything before it dies?

Comment 6

[Didier Moens]

Comment #5 : no output whatsoever.

I could provide a (filtered ?) strace, if that would be beneficial.

Comment 7

[Andrew Schultz]

> not experienced with gdb stacktrace

here's the simplest way way
% mozilla -g -d gdb http://www.brainjar.com/
...
(gdb) b main
Breakpoint 1 at 0x8051b7d
(gdb) run
...
Breakpoint 1, 0x08051b7d in main ()
(gdb) b exit
Breakpoint 2 at 0x4202b0f6
(gdb) cont
...
(break due to crash or hitting "exit")
(gdb) bt
(prints stacktrace, copy paste this into a file and attach it here)

more info at http://www.mozilla.org/unix/debugging-faq.html
You need the "b exit" because Mozilla might not actually be crashing.

> I wouldn't know where to look for the info to send along with the talkback
It's included automagically on Linux as well.

> I've always wanted to trace my Windows talkbacks
http://ftp.mozilla.org/pub/data/crash-data/

Comment 8

[Didier Moens]

When running "mozilla -g -d gdb http://www.brainjar.com/", I never get to the
gdb console ! Brainjar comes up, and Mozilla exits. Any rationale for that ?

(note : replacing 'mozilla' with 'phoenix' gives me the (gdb) prompt).



However, seems like I've found the culprit.

I'm running a dual-boot Win2K / RHL8.0 ; I've included the windows
fonts-directory in my RHL fontpath : this provides my RHL-desktop with all
Windows-installed fonts.

Most fonts in the windir are TrueType ones ; some are not.

When a fontstyle with a non-TrueType font is installed, Mozilla/gtk2 exits.

{ font-family: "MS Sans Serif", Arial, sans-serif; }   : crash/exit
{ font-family: "Comic Sans MS", Arial, sans-serif; }   : no crash

This problem does not occur with non-gtk2-enabled builds.

I presume a lot of websites define non-TrueType fonts in their styles, so the
impact of this behaviour could be quite serious.

Comment 9

[Andrew Schultz]

ah, yes.  the RPM build doesn't do '-g'.  you need to start mozilla normally,
and then do
% gdb /usr/lib/mozilla-1.2/mozilla-bin _PID_OF_MOZILLA_

Comment 10

[Didier Moens]

Attachment: SIGSEGV stack trace

Comment 11

[Andrew Schultz]

thanks
==> Layout

Comment 12

[Andrew Schultz]

worksforme with linux trunk CVS xft/gtk2

Comment 13

[Didier Moens]

Attachment: SIGSEGV stack trace 2002111607_trunk_rh8_gtk2

Still segfaulting.

Comment 14

[Didier Moens]

Andrew, do you have any MS VGA (non-TrueType) fonts in your fontpath ?

BTW : thanks for the gdb intro. :)

Comment 15

[Andrew Schultz]

> Andrew, do you have any MS VGA (non-TrueType) fonts in your fontpath ?

I don't think so.  What is their extension?  (fon?)

> BTW : thanks for the gdb intro. :)

gdb is my friend.  :)

Comment 16

[Andrew Schultz]

gtk2 is probably not causing this problem, just doing something layout doesn't
expect

Comment 17

[Didier Moens]

MS Sans Serif : SSERIFE.FON
MS Serif : SERIFE.FON
Terminal : VGAOEM_0.FON
...

If only this would be free software, I'd attach a copy.  ;)

These fonts are easily distinguished in a GTK-font selector : their characters
are represented by weird, 'domino'-like symbols. GEdit and the like allow these
fonts to be selected, and although the output is incomprehensible, those apps do
not crash.

Comment 18

[Andrew Schultz]

I pulled the .fon fonts out of my windoze directory, but still don't crash at
the URL.  There is no indication that Mozilla even cares that the .fon fonts
exist (I can't select them in Edit->Preferences->Appearance->Fonts)

Comment 19

[Didier Moens]

Andrew, to check whether your system recognizes the .FON fonts :

1. can you select the fonts in a GTK app (e.g. GEdit) ?
2. did you add your Windows fonts dir to your /etc/fonts/fonts.conf ?

Comment 20

[Didier Moens]

I just confirmed the crashing behaviour on a fresh RHL 8.0 installation :

1. install RHL 8.0
2. install mozilla-1.2b-2002111811_trunk_rh8_gtk2
3. copy sserife.fon ('MS Sans Serif') to ~/.fonts
4. start mozilla, visit test page
5. crash

Step 3. is the mitigating factor.


Note : concerning the 'domino'-like representation of these fonts (comment #17)
: these are the hex-representations (0041, 0042, 0043, ...) of the ASCII values
in a rectangular icon.

Comment 21

[Andrew Schultz]

> 3. copy sserife.fon ('MS Sans Serif') to ~/.fonts

ok, that at least got it into gedit, but Mozilla still doesn't list the font as
available (and the URL still works).  Is the font listed for you in the font
preferences?

Comment 22

[Didier Moens]

Attachment: Minimal HTML test suite

No, "MS Sans Serif" (< 'sserife.fon') is not listed in Mozilla's font list ;
"Microsoft Sans Serif" does, but that one's related to the genuine
'micross.ttf' TTF-font.

I attached a skeleton test page, which consistently crashes Mozilla, provided
'sserife.fon' is in the font path.
Replacing "MS Sans Serif" with "Arial" in the CSS-rule yields no problems.

Comment 23

[Andrew Schultz]

ok, I crash with the RPM build...

marking NEW for further investigation

Comment 24

[Andrew Schultz]

Attachment: stack with symbols

xft was the ingredient I was missing.  this stack is from a CVS build.

fm is NULL.
GetNormalLineHeight does not check the return value from GetMetricsFor
neither does TextStlye (nsTextFrame.cpp:570)

it appears that layout assumes the font is ok, but it obviously isn't.	Is
xft/gtk2 telling layout that the font is there and then changes its mind when
layout actually asks for the font?

this can be wallpapered in layout (perhaps the checks are a good idea anyway),
but is there something farther up the line that can be done?

Comment 25

[Andrew Schultz]

Attachment: stack with symbols and a bit less optimization

Comment 26

[timeless]

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

Comment 27

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

->blizzard

Comment 28

[Andreas Øye]

I had a similar problem with this today. It was caused by the following: Mount
ntfs partition on laptop. copy windows/fonts/*.tff to /usr/share/fonts/ttf (made
by me) and run fc-cache. Restart mozilla and watch it die upon loading
www.linuxtoday.com and www.google.com.

Suddenly remember that the files in ntfs are perms 600 and owned by root, so the
user with mozilla cannot access them, chmod 644 on the truetype fonts and lo and
behold, mozilla works great. (look good too ;) 

Hope this is useful with your problem.  If it is it saves me from entering a
bug. :-P

Andreas.

Comment 29

[Didier Moens]

Comment #28 : the crash as described in this bug does not seem to be correlated
to file permissions, as all my fonts are world-readable ; it is explicitly
invoked by accessing .fon fonts.

Guess you'll have to file a bug.  :/

Comment 30

[Andrew Schultz]

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

Comment 31

[Nicolas PENINGUY]

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

Comment 32

[Didier Moens]

Another test page, crashing Mozilla (mozilla.org 1.2.1-0_rh8_xft RPM's) :
 
http://news.com.com/2100-1001-982512.html (titled "IBM: Linux is the 'logical
successor'")

This page is linked to by Linux Today, so I suppose this crash could get some
wide coverage.

Comment 33

[Boris Zbarsky [:bzbarsky]]

unsetting kevin's milestone/priority crap

Comment 34

[Sylvain Pasche]

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

Comment 35

[Sylvain Pasche]

There may be some more info in the bug #193497

Like a stack trace:
http://bugzilla.mozilla.org/attachment.cgi?id=114579

Comment 36

[Christopher Blizzard (:blizzard)]

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

Comment 37

[Christopher Blizzard (:blizzard)]

see also:

http://nexp.cs.pdx.edu/cgi-bin/bugzilla/show_bug.cgi?id=48

Comment 38

[Didier Moens]

Comment #37 : this implies we wait for a new version of fontconfig to be
included in future releases of the Linux distros ?

Comment 39

[Sylvain Pasche]

A few comments which may be useful:

I tried with the following testcase:

<div style="font-family: 'MS Sans Serif';">test</div>

First, with mozilla 1.3b Gecko/20030318, built with xft, and 
there was no crash !

Then, I tried with galeon 1.3.3, built whith the same source tree
that mozilla above, and it crashed:

....
#5  0x40c0c9d8 in sigaction () from /lib/libc.so.6
#6  0x4165a192 in ComputeLineHeight (aPresContext=0x84faa80, 
    aRenderingContext=0x88b4128, aStyleContext=0x84fd208)
    at ../../../../dist/include/xpcom/nsCOMPtr.h:643
#7  0x4165a281 in nsHTMLReflowState::CalcLineHeight(nsIPresContext*,
nsIRenderingContext*, nsIFrame*) (aPresContext=0x84faa80,
aRenderingContext=0x88b4128, 
    aFrame=0x0) at ../../../../dist/include/xpcom/nsCOMPtr.h:643
#8  0x4163da7c in nsBlockReflowState (this=0xbfffd600, 
    aReflowState=@0xbfffd960, aPresContext=0x84faa80, aFrame=0x89a539c, 
    aMetrics=@0xbfffda74, aBlockMarginRoot=0) at nsBlockReflowState.cpp:179
....

Then, I applied the small fontconfig patch found on 
http://nexp.cs.pdx.edu/cgi-bin/bugzilla/show_bug.cgi?id=48
and galeon did not crash any more.

So this is definitely a fontconfig bug, I was just surprised it crashed Gecko
browsers and not mozilla (at least in my case).

Comment 40

[Olivier Cahagne]

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

Comment 41

[Christopher Blizzard (:blizzard)]

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

Comment 42

[Sameer]

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

Comment 43

[Christopher Blizzard (:blizzard)]

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

Comment 44

[Christopher Blizzard (:blizzard)]

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

Comment 45

[Drew "DanteAliegri" Ogle]

I applied that patch to fontconfig, and my testcase from 200066 no longer crashes,
so I'd say this probably is a fontconfig bug, not a mozilla one.

Comment 46

[Andrew Schultz]

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

Comment 47

[Andrew Schultz]

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

Comment 48

[Michael Stadlbauer]

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

Comment 49

[Olivier Cahagne]

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

Comment 50

[Olivier Cahagne]

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

Comment 51

[Mitch]

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

Comment 52

[Olivier Cahagne]

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

Comment 53

[Andrew Schultz]

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

Comment 54

[R.K.Aa.]

Attachment: backtrace

a current trunk CVS crashes at http://artlog.co.il/telaviv/intro.html - but
Mozilla 1.4 release does NOT crash there. I use xfs as a fontserver, no
aliasing.

Comment 55

[R.K.Aa.]

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

Comment 56

[Jungshik Shin]

re: comment #24
> this can be wallpapered in layout (perhaps the checks are a good idea anyway),

  What do layout people think of the idea? fontconfig fix will get propagated,
but isn't it a good idea in general to check  in places like 
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsHTMLReflowState.cpp#2313
?

Comment 57

[Christopher Blizzard (:blizzard)]

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

Comment 58

[Olivier Cahagne]

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

Comment 59

[Jungshik Shin]

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

Comment 60

[R.K.Aa.]

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

Comment 61

[Seth]

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

Comment 62

[Christopher Blizzard (:blizzard)]

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

Comment 63

[Christopher Blizzard (:blizzard)]

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

Comment 64

[Andrew Schultz]

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

Comment 65

[Boris Zbarsky [:bzbarsky]]

This is being reported a lot via talkback for Firefox (not for suite, since this
is an xft issue).

In particular, the following two entries from the "Smart Analysis" for 0.10.1 on
Linux:

(5) 90  GetNormalLineHeight  
(12) 50  nsTextFrame::TextStyle::TextStyle  

(I suspect the latter is caused by the same bug as the former).  These are the
5th and 12th most common crash on Linux; together they would be the third most
common one.

Based on that, requesting blocking-aviary status.

Comment 66

[chris hofmann]

dbaron, can you have a look?

Comment 67

[Brendan Eich [:brendan]]

Jay, does this bug deserve topcrash?  It looks like it.  Wondering whether it
was on its way to having that keyword already, or if not, why not?

/be

Comment 68

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I've analyzed problems in some other bug where our Xft code doesn't handle
certain errors correctly -- if it finds an unreadable font file it returns null
font metrics instead of trying the next font.  That problem may or may not be
the cause of the majority of the crashes reported in this bug.

Comment 69

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

...unreadable font file or having a nonexistent font listed in fonts.cache-1,
which can be caused by https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111973

Comment 70

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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

Comment 71

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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

Comment 72

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

See also bug 183729 and bug 136248.

Comment 73

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I actually can't reproduce using the steps in comment 20 on Fedora Core 2.

Comment 74

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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

Comment 75

[Jay Patel [:jay]]

Adding FF10PR1 to summary and topcrash+ keyword. This is a topcrasher from
looking at recent Firefox Talkback data (there are a good number of crashes for
FFTrunk, FFBranch and FF10PR1).  

Comment 76

[Ryan Polk (Quark)]

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

Comment 77

[Brian Ryner (not reading)]

So no matter what we do, the problem here is that fontconfig is handing back a
single font that does not have the requested character (even when we request all
matching fonts).  This probably indicates that fontconfig itself is giving up if
it encounters a font it can't deal with.

There are a few ways we could solve this:

- If we don't match anything, try again with the first family in the pattern
omitted.  Or with only the generic font-family.
- Have just a single last-ditch FontMetrics object we can return if there's
nothing else.  Could be the FontMetrics for the system DefaultFont.
- Start null-checking this in layout.  The assumption that getting a FontMetrics
object will never fail seems quite fragile after skimming various
implementations of the FontMetrics Init() method.  Maybe we could fall back to
the default document font or the font of the parent frame.

dbaron, bz, any thoughts?

Comment 78

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(In reply to comment #77)
> - Have just a single last-ditch FontMetrics object we can return if there's
> nothing else.  Could be the FontMetrics for the system DefaultFont.

We actually already do this, *if* we've loaded a font already.  So it seems
reasonable to make this code a little more robust.

Comment 79

[Boris Zbarsky [:bzbarsky]]

> This probably indicates that fontconfig itself is giving up if
> it encounters a font it can't deal with.

Sounds like a bug in fontconfig to me.  Can we escalate to them?

For the rest, I agree with comment 78, but I'm by no means an expert on this code...

Comment 80

[Brian Ryner (not reading)]

Attachment: patch

Here's one thing we could try (which fixes the testcase in this bug).  If
FcFontSort() returns a fontset with only 1 font, it's pretty clear that we're
in a bad state.  It's supposed to return all installed fonts, sorted by
closeness to the pattern.  If we get into this state, there are two
possibilities:

- We've hit this fontconfig bug we've been discussing
- The user only has a single font installed, and it doesn't support the
character 'a'.	I think this is even more of an edge case.

So, when this happens, we can try rematching using only the CSS generic font
family (our xft code makes this "serif" if none is given).  This gives a fairly
reasonable substitute font.

Comment 81

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 161996 [details] [diff] [review]
patch

>+        if (!set || set->nfont == 1) {
...
>+            FcFontSetDestroy(set);

Either don't check !set on the first of these lines or check if (set) for the
second.

With that, r=dbaron.

Comment 82

[Christopher Blizzard (:blizzard)]

Comment on attachment 161996 [details] [diff] [review]
patch

Wow, what a hack.  But it makes sense to try to do this.

Just out of curiousity, do we know what versions this in which this is a
problem?  Can we just blacklist based on version?

Comment 83

[Brian Ryner (not reading)]

Comment on attachment 161996 [details] [diff] [review]
patch

checked into trunk; requesting branch approvals

Comment 84

[chris hofmann]

Comment on attachment 161996 [details] [diff] [review]
patch

a=chofmann for the branches

Comment 85

[Brian Ryner (not reading)]

checked in everywhere

Comment 86

[Jay Patel [:jay]]

blizzard:  From looking at the Talkback data, this has been a topcrasher since
FF 0.9.0, TB 0.7.0 and Mozilla 1.7.0.  It might have been around earlier than
that, but it is safe to say anything off the Mozilla 1.7 and Aviary branches
before this fix has the problem.

Comment 87

[Tuukka Tolvanen (sp3000)]

I still crash @ GetNormalLineHeight with these:
    http://www.brainjar.com/
    attachment 106795 [details]

these wfm, no crash:
    http://news.com.com/2100-1001-982512.html
        *** Warning: nsFontMetricsXft was passed a pixel size of 0,000000
    http://artlog.co.il/telaviv/intro.html
        rkaa crashed @ TextStyle here, I do see that on some other pages

linux gtk2 xft seamonkey trunk cvs 2004-10-20-15Z
linux gtk2 xft firefox aviary cvs 2004-10-18-20Z

Comment 88

[Tuukka Tolvanen (sp3000)]

Attachment: bt full (attachment 106795, linux gtk2 xft seamonkey trunk 2004-10-20-15Z)

Comment 89

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The stack trace of the crash doesn't help.  What might help is an explanation of
what caused the Xft code to return null font metrics.

Comment 90

[Robin Monks]

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

Comment 91

[Jay Patel [:jay]]

This is currently the #1 topcrash in early Firefox 1.0 RC2 data:

Count   Offset    Real Signature
[ 23   GetNormalLineHeight() c2a833a7 - GetNormalLineHeight() ]
 
     Crash date range: 04-NOV-04 to 04-NOV-04
     Min/Max Seconds since last crash: 0 - 0
     Min/Max Runtime: 0 - 0
 
     Count   Platform List 
     23   [Linux 2.6.8.1]      
 
     Count   Build Id List 
     23   2004110319
 
     No of Unique Users         2
 
 Stack trace(Frame) 

	 GetNormalLineHeight()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsHTMLReflowState.cpp
 line 2124] 
	 ComputeLineHeight()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsHTMLReflowState.cpp
 line 704] 
	 nsHTMLReflowState::CalcLineHeight()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsHTMLReflowState.cpp
 line 2191] 
	 nsBlockReflowState::nsBlockReflowState()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockReflowState.cpp
 line 165] 
	 nsBlockFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 687] 
	 nsBlockReflowContext::ReflowBlock()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockReflowContext.cpp
 line 546] 
	 nsBlockFrame::ReflowBlockFrame()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 95] 
	 nsBlockFrame::ReflowLine()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 545] 
	 nsBlockFrame::ReflowDirtyLines()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 2098] 
	 nsBlockFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 817] 
	 nsContainerFrame::ReflowChild()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp
 line 982] 
	 CanvasFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsHTMLFrame.cpp
 line 554] 
	 nsBoxToBlockAdaptor::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp
 line 884] 
	 nsBoxToBlockAdaptor::DoLayout()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp
 line 628] 
	 nsBox::Layout()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsBox.cpp
 line 1016] 
	 nsScrollBoxFrame::DoLayout()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp
 line 337] 
	 nsBox::Layout()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsBox.cpp
 line 1016] 
	 nsContainerBox::LayoutChildAt()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsContainerBox.cpp
 line 654] 
	 nsGfxScrollFrameInner::Layout()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp
 line 1421] 
	 nsGfxScrollFrame::DoLayout()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp
 line 1272] 
	 nsBox::Layout()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsBox.cpp
 line 1016] 
	 nsBoxFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp
 line 868] 
	 nsGfxScrollFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp
 line 870] 
	 nsContainerFrame::ReflowChild()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp
 line 982] 
	 ViewportFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsViewportFrame.cpp
 line 252] 
	 IncrementalReflow::Dispatch()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 53] 
	 PresShell::ProcessReflowCommands()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 6397] 
	 ReflowEvent::HandleEvent()  
	 PL_HandleEvent()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/threads/plevent.c
 line 674] 
	 PL_ProcessPendingEvents()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/threads/plevent.c
 line 608] 
	 nsEventQueueImpl::ProcessPendingEvents()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/threads/nsEventQueue.cpp
 line 395] 
	 event_processor_callback()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsAppShell.cpp
 line 67] 
	 libglib-2.0.so.0 + 0x4932f (0x4060632f)  
	 libglib-2.0.so.0 + 0x23f25 (0x405e0f25)  
	 libglib-2.0.so.0 + 0x25078 (0x405e2078)  
	 libglib-2.0.so.0 + 0x253ac (0x405e23ac)  
	 libglib-2.0.so.0 + 0x25a61 (0x405e2a61)  
	 libgtk-x11-2.0.so.0 + 0x1180a3 (0x402d40a3)  
	 nsAppShell::Run()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsAppShell.cpp
 line 144] 
	 nsAppShellService::Run()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpfe/appshell/src/nsAppShellService.cpp
 line 495] 
	 xre_main()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/toolkit/xre/nsAppRunner.cpp
 line 692] 
	 main()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/browser/app/nsBrowserApp.cpp
 line 59] 
	 libc.so.6 + 0x15936 (0x40988936)   
 
     (1719008)	Comments: puff@darkslack:/scarichi_maxtor/firefox$ ./firefox ***
nsExtensionManager::_disableObsoleteExtensions - failure  catching exception so
finalize window can close *** loading the extensions datasource ***
ExtensionManager:_updateManifests: no access
     (1719008)	Comments:  privileges to application directory  skipping. ***
loading the extensions datasource *** ExtensionManager:_updateManifests: no
access privileges to application directory  skipping. ./run-mozilla.sh: line
451:  1410 Segmentation fault      "$prog"
     (1719008)	Comments:  ${1+"$@"} 
     (1718879)	URL: www.libero.it
     (1718879)	Comments: *** loading the extensions datasource ***
ExtensionManager:_updateManifests: no access privileges to application directory
 skipping. *** loading the extensions datasource ***
ExtensionManager:_updateManifests: no access privileges to application
     (1718879)	Comments:  directory  skipping. ./run-mozilla.sh: line 451:  1047
Segmentation fault      "$prog" ${1+"$@"} 
     (1718840)	URL: www.libero.it
     (1718840)	Comments: i don't know what to do
     (1717998)	URL: www.libero.it
     (1717998)	Comments: it seems it crashes with normal users. Root user goes
well  ./run-mozilla.sh: line 451: 27313 Segmentation fault      "$prog" ${1+"$@"} 
     (1717975)	URL: www.libero.it
     (1717975)	Comments: pescio@darkslack:~/firefox$ ./firefox ./run-mozilla.sh:
line 451: 27252 Segmentation fault      "$prog" ${1+"$@"} 
 
====================================================================================================
     Count   Offset    Real Signature
[ 1   GetNormalLineHeight() cd8a9ae0 - GetNormalLineHeight() ]
[ 1   GetNormalLineHeight() a0122433 - GetNormalLineHeight() ]
[ 1   GetNormalLineHeight() 179016a6 - GetNormalLineHeight() ]
 
     Crash date range: 04-NOV-04 to 04-NOV-04
     Min/Max Seconds since last crash: 0 - 0
     Min/Max Runtime: 0 - 0
 
     Count   Platform List 
     3   [Linux 2.6.8-1.521smp]      
 
     Count   Build Id List 
     3   2004110319
 
     No of Unique Users         1
 
 Stack trace(Frame) 

	 GetNormalLineHeight()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsHTMLReflowState.cpp
 line 2124] 
	 ComputeLineHeight()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsHTMLReflowState.cpp
 line 704] 
	 nsHTMLReflowState::CalcLineHeight()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsHTMLReflowState.cpp
 line 2191] 
	 nsBlockReflowState::nsBlockReflowState()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockReflowState.cpp
 line 165] 
	 nsBlockFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 687] 
	 nsContainerFrame::ReflowChild()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp
 line 982] 
	 nsTableCellFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/table/src/nsTableCellFrame.cpp
 line 439] 
	 nsContainerFrame::ReflowChild()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp
 line 982] 
	 nsTableRowFrame::ReflowChildren()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/table/src/nsTableRowFrame.cpp
 line 965] 
	 nsTableRowFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/table/src/nsTableRowFrame.cpp
 line 1396] 
	 nsContainerFrame::ReflowChild()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp
 line 982] 
	 nsTableRowGroupFrame::ReflowChildren()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp
 line 432] 
	 nsTableRowGroupFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp
 line 1289] 
	 nsContainerFrame::ReflowChild()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp
 line 982] 
	 nsTableFrame::ReflowChildren()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/table/src/nsTableFrame.cpp
 line 3250] 
	 nsTableFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/table/src/nsTableFrame.cpp
 line 982] 
	 nsContainerFrame::ReflowChild()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp
 line 982] 
	 nsTableOuterFrame::OuterReflowChild()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/table/src/nsTableOuterFrame.cpp
 line 1335] 
	 nsTableOuterFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/table/src/nsTableOuterFrame.cpp
 line 2000] 
	 nsBlockReflowContext::ReflowBlock()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockReflowContext.cpp
 line 546] 
	 nsBlockFrame::ReflowBlockFrame()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 95] 
	 nsBlockFrame::ReflowLine()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 545] 
	 nsBlockFrame::ReflowDirtyLines()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 2098] 
	 nsBlockFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 817] 
	 nsBlockReflowContext::ReflowBlock()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockReflowContext.cpp
 line 546] 
	 nsBlockFrame::ReflowBlockFrame()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 95] 
	 nsBlockFrame::ReflowLine()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 545] 
	 nsBlockFrame::ReflowDirtyLines()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 2098] 
	 nsBlockFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 817] 
	 nsBlockReflowContext::ReflowBlock()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockReflowContext.cpp
 line 546] 
	 nsBlockFrame::ReflowBlockFrame()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 95] 
	 nsBlockFrame::ReflowLine()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 545] 
	 nsBlockFrame::ReflowDirtyLines()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 2098] 
	 nsBlockFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp
 line 817] 
	 nsContainerFrame::ReflowChild()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp
 line 982] 
	 CanvasFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsHTMLFrame.cpp
 line 554] 
	 nsBoxToBlockAdaptor::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp
 line 884] 
	 nsBoxToBlockAdaptor::DoLayout()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp
 line 628] 
	 nsBox::Layout()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsBox.cpp
 line 1016] 
	 nsScrollBoxFrame::DoLayout()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp
 line 337] 
	 nsBox::Layout()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsBox.cpp
 line 1016] 
	 nsBoxFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp
 line 868] 
	 nsContainerFrame::ReflowChild()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp
 line 982] 
	 ViewportFrame::Reflow()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsViewportFrame.cpp
 line 252] 
	 IncrementalReflow::Dispatch()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 53] 
	 PresShell::ProcessReflowCommands()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 6397] 
	 ReflowEvent::HandleEvent()  
	 PL_HandleEvent()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/threads/plevent.c
 line 674] 
	 PL_ProcessPendingEvents()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/threads/plevent.c
 line 608] 
	 nsEventQueueImpl::ProcessPendingEvents()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpcom/threads/nsEventQueue.cpp
 line 395] 
	 event_processor_callback()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsAppShell.cpp
 line 67] 
	 libglib-2.0.so.0 + 0x4979f (0x00cfb79f)  
	 libglib-2.0.so.0 + 0x241e2 (0x00cd61e2)  
	 libglib-2.0.so.0 + 0x252d8 (0x00cd72d8)  
	 libglib-2.0.so.0 + 0x25610 (0x00cd7610)  
	 libglib-2.0.so.0 + 0x25c53 (0x00cd7c53)  
	 libgtk-x11-2.0.so.0 + 0x10eff3 (0x03adeff3)  
	 nsAppShell::Run()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/widget/src/gtk2/nsAppShell.cpp
 line 144] 
	 nsAppShellService::Run()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/xpfe/appshell/src/nsAppShellService.cpp
 line 495] 
	 xre_main()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/toolkit/xre/nsAppRunner.cpp
 line 692] 
	 main()
[/builds/tinderbox/firefox-1.0/Linux_2.4.20-28.8_Clobber/mozilla/browser/app/nsBrowserApp.cpp
 line 59] 
	 libc.so.6 + 0x14ad4 (0x0041bad4)   
 
     (1726352)	URL: http://www.nana.co.il (almost any domain in nana.co.il) and
http://xslf.com
     (1726310)	URL: http://www.nana.co.il (almost any domain in nana.co.il) and
http://xslf.com
     (1726310)	Comments: Surfing sites such as nana.co.il or xslf.com. The
second is a site which should have no HTML errors.   Both works well for others
with the same version.
 

Comment 92

[Jay Patel [:jay]]

Just wanted to note that most of these recent crashes are only from 1 or 2
users, so it appears more critical than it probably is.

Comment 93

[Jason]

(In reply to comment #91)
> This is currently the #1 topcrash in early Firefox 1.0 RC2 data:

It's still pretty high for Linux users in 1.0 release.

>      (1718879)	URL: www.libero.it
>      (1718840)	URL: www.libero.it
>      (1717998)	URL: www.libero.it
>      (1717998)	Comments: it seems it crashes with normal users. Root user goes
> well  ./run-mozilla.sh: line 451: 27313 Segmentation fault      "$prog" ${1+"$@"} 
>      (1717975)	URL: www.libero.it
====================================================================================================
>      Count   Platform List 
>      3   [Linux 2.6.8-1.521smp]      
>      (1726352)	URL: http://www.nana.co.il (almost any domain in nana.co.il) and
> http://xslf.com
>      (1726310)	URL: http://www.nana.co.il (almost any domain in nana.co.il) and
> http://xslf.com
>      (1726310)	Comments: Surfing sites such as nana.co.il or xslf.com. The
> second is a site which should have no HTML errors.   Both works well for others
> with the same version.

I have no crashes browsing anywhere inside xslf.com or *.nana.co.il or
www.libero.it.  I've sent 5 talkbacks for this crash today and yesterday.  I can
reproduce the crash at will with forums.devshed.com (which works fine from FF10
on Win2k) and www.ubuntulinux.org -- I cannot browse anything inside either site.

This is (still) looking like a fonts issue, yes?  (Widely varying font installs
could easily account for sites crashing some and not others.)  Is there any
diagnostic info I can provide?

Comment 94

[Tuukka Tolvanen (sp3000)]

fwiw...

My trunk pango/xft opt firefox build does not crash on the testcases, but
outputs lines such as:
** (Gecko:23097): WARNING **: Cannot open font file for font MS Sans Serif 8
** (Gecko:23097): WARNING **: Cannot open font file for font MS Sans Serif 12
** (Gecko:23097): WARNING **: Cannot open font file for font MS Sans Serif 9.75

Throwing away sserife.fon and sseriff.fon stops my trunk debug seamonkey build
from crashing on the testcases.

Comment 95

[Jason]

After installing and updating some packages I'm now able to browse all the sites
listed above with the same FF10 release.  
What probably fixed it was upgrading from XFree86 v4.3.0.1 to
xorg-x11-6.8.1-3mdk.  I also installed t1lib1-1.3.1-15mdk and upgraded my xpdf.

No font warnings (yet) either.

HTH

(In reply to comment #94)
> fwiw...
> [...gecko font warnings...]
>
> Throwing away sserife.fon and sseriff.fon stops my trunk debug seamonkey build
> from crashing on the testcases.

Comment 96

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

A way I've found to reproduce this crash (on Fedora Core 3, with the
fonts-hebrew RPM installed) is just by loading the URL:
  data:text/html,<p style='font-family: Miriam Mono'>&#1488;&#1489;&#1490;&#1491;&#1492;&#1493;&#1494;</p>
The font in question is a postscript font (pfa and afm files).

What happens is that XftFontOpenPattern returns null in nsFontXft::GetXftFont,
which thus returns null, so nsFontMetricsXft::CacheFontMetrics returns failure
which propagates through nsFontMetricsXft::RealizeFont and
nsFontMetricsXft::Init to nsFontCache::GetMetricsFor, which returns null to the
caller.

Comment 97

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: patch that fixes crash in comment 96

This fixes the crash in comment 96 by making the calls to GetXftFont happen
earlier.  It's worth noting that we don't lose anything by making them less
lazy, since all of the callers of FindFont call GetXftFont on the result
eventually (for the FindFont call in RealizeFont, near the beginning of
CacheFontMetrics; for the FindFont call in EnumerateXftGlyphs, via any the 4
callbacks in either nsFontXft::DrawStringSpec or
nsFontXft[Custom]::GetTextExtents32.

It's also worth noting that the testcase in comment 96 ends up displaying
garbage for me with this patch.  Perhaps that's all Xft can do for us.

Comment 98

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: patch that fixes crash when fc.cache-1 files have entries for fonts that no longer exist

This removes a few more unneeded checks.

(This patch actually makes us do less work in all the cases where we wouldn't
have crashed without it.)

Comment 99

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Actually, the URL on which I was crashing is the following:
  data:text/html;charset=iso-8859-1,<p style='font-family: Miriam
Mono'>%D7%90%D7%91%D7%92%D7%93%D7%94%D7%95</p>

The one above is what I get when I paste the line with Hebrew into a iso-8859-1
submitted form, and that one actually doesn't crash.  Presumably it doesn't
crash with charset=utf-8 either.

Comment 100

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(Which means that displaying garbage was actually the right thing to do, since
it is garbage.  That's what I get for changing my intl.charset.default pref from
UTF-8 back to the default of iso-8859-1 so I could read broken Web pages.)

Comment 101

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Er, actually, I don't know that any of those don't crash, since I was testing in
a patched build.  They probably do.  (I don't see any font variation when I name
those fonts.)

Comment 102

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

And it turns out installing fonts-hebrew in FC3 isn't enough -- it requires that
it be upgraded from some earlier version, probably with an old fontconfig
present during one of the earlier upgrades.  (I'm not sure which.)  This causes
the renaming of some of the fonts to trigger the problem in comment 69.

Comment 103

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: patch that fixes crash when fc.cache-1 files have entries for fonts that no longer exist

This is like the previous patch but it removes the bad fonts from mLoadedFonts
(lazily) so that they don't continue to slow things down (with repeated
attempts to load the font).  (It assumes that if the font fails to load once,
it will continue to fail.)

Comment 104

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Although removing the fonts might not be so good for cases where we're hitting
this because of out-of-memory, because we might then remove all the fonts and
crash that way.  So maybe I should take that bit out.

Comment 105

[Nickolay_Ponomarev]

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

Comment 106

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Fix checked in to trunk, 2005-01-04 20:04 -0800.

Removing keywords indicating being fixed on branch, since it was reopened due to
not being fixed on branch or trunk (and talkback data show it's not fixed on the
Aviary branch, at least).

Comment 107

[Jungshik Shin]

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

Comment 108

[Asa Dotzler [:asa]]

Comment on attachment 169534 [details] [diff] [review]
patch that fixes crash when fc.cache-1 files have entries for fonts that no longer exist

a=asa for branches checkin.

Comment 109

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

attachment 169534 [details] [diff] [review] checked in to AVIARY_1_0_1_20050124_BRANCH and
MOZILLA_1_7_BRANCH, 2005-02-12 12:08 -0800.

Comment 110

[Lorenzo Colitti]

This appears to have caused bug 282453; the XFT code still crashes if it can't
find a valid font.

Comment 111

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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

Comment 112

[Andrew Schultz]

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

Comment 113

[Adam Guthrie]

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

Comment 114

[Adam Guthrie]

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

Comment 115

[Adam Guthrie]

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