Closed Bug 180309 Opened 17 years ago Closed 15 years ago

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

Categories

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

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: d.bz-mozilla, Assigned: dbaron)

References

()

Details

(5 keywords, Whiteboard: [patch])

Crash Data

Attachments

(7 files, 4 obsolete files)

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.
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.

Keywords: crash
can you post Talkback ID for this crash
'mozilla/bin/components/talkback/talkback' or a stack trace with GDB ?
Keywords: stackwanted
oops, I didn't read "Mozilla exits without warning (no additional dump info when
launched from shell)", sorry.
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 ?).
if you run mozilla from a terminal, does it print anything before it dies?
Comment #5 : no output whatsoever.

I could provide a (filtered ?) strace, if that would be beneficial.
> 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/
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.
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_
Summary: Crash while loading page → [gtk2] Crash while loading page
Attached file SIGSEGV stack trace (obsolete) —
thanks
==> Layout
Assignee: asa → other
Component: Browser-General → Layout
Keywords: stackwanted
QA Contact: asa → ian
worksforme with linux trunk CVS xft/gtk2
Still segfaulting.
Attachment #106507 - Attachment is obsolete: true
Andrew, do you have any MS VGA (non-TrueType) fonts in your fontpath ?

BTW : thanks for the gdb intro. :)
> 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.  :)
gtk2 is probably not causing this problem, just doing something layout doesn't
expect
Summary: [gtk2] Crash while loading page → Crash while loading page [@ GetNormalLineHeight]
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.
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)
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 ?
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.

> 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?
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.
ok, I crash with the RPM build...

marking NEW for further investigation
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Target Milestone: --- → Future
Summary: Crash while loading page [@ GetNormalLineHeight] → Crash while loading page with MS .fon font [@ GetNormalLineHeight]
Attached file stack with symbols (obsolete) —
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?
Attachment #106967 - Attachment is obsolete: true
Summary: Crash while loading page with MS .fon font [@ GetNormalLineHeight] → Xft Crash while loading page with MS .fon font [@ GetNormalLineHeight]
*** Bug 182901 has been marked as a duplicate of this bug. ***
->blizzard
Assignee: other → blizzard
Blocks: xft_tracking
Component: Layout → Layout: Fonts and Text
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 #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.  :/
*** Bug 183621 has been marked as a duplicate of this bug. ***
Keywords: testcase
*** Bug 190692 has been marked as a duplicate of this bug. ***
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.
unsetting kevin's milestone/priority crap
Priority: P1 → --
Target Milestone: Future → ---
*** Bug 193497 has been marked as a duplicate of this bug. ***
There may be some more info in the bug #193497

Like a stack trace:
http://bugzilla.mozilla.org/attachment.cgi?id=114579
No longer blocks: 193497
*** Bug 198123 has been marked as a duplicate of this bug. ***
Comment #37 : this implies we wait for a new version of fontconfig to be
included in future releases of the Linux distros ?
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).
*** Bug 198718 has been marked as a duplicate of this bug. ***
*** Bug 198638 has been marked as a duplicate of this bug. ***
*** Bug 199027 has been marked as a duplicate of this bug. ***
*** Bug 189948 has been marked as a duplicate of this bug. ***
*** Bug 200066 has been marked as a duplicate of this bug. ***
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.
*** Bug 201679 has been marked as a duplicate of this bug. ***
*** Bug 204105 has been marked as a duplicate of this bug. ***
*** Bug 193357 has been marked as a duplicate of this bug. ***
*** Bug 206993 has been marked as a duplicate of this bug. ***
*** Bug 208606 has been marked as a duplicate of this bug. ***
*** Bug 206170 has been marked as a duplicate of this bug. ***
*** Bug 211682 has been marked as a duplicate of this bug. ***
*** Bug 198083 has been marked as a duplicate of this bug. ***
Attached file 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.
*** Bug 214595 has been marked as a duplicate of this bug. ***
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
?
*** Bug 198767 has been marked as a duplicate of this bug. ***
*** Bug 224773 has been marked as a duplicate of this bug. ***
*** Bug 235198 has been marked as a duplicate of this bug. ***
*** Bug 238394 has been marked as a duplicate of this bug. ***
*** Bug 244054 has been marked as a duplicate of this bug. ***
*** Bug 249945 has been marked as a duplicate of this bug. ***
*** Bug 253770 has been marked as a duplicate of this bug. ***
*** Bug 263491 has been marked as a duplicate of this bug. ***
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.
Flags: blocking-aviary1.0?
dbaron, can you have a look?
Assignee: blizzard → dbaron
Flags: blocking-aviary1.0? → blocking-aviary1.0+
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
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.
...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
*** Bug 246825 has been marked as a duplicate of this bug. ***
*** Bug 246836 has been marked as a duplicate of this bug. ***
Blocks: 183729
I actually can't reproduce using the steps in comment 20 on Fedora Core 2.
*** Bug 240757 has been marked as a duplicate of this bug. ***
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).  
Keywords: topcrash+
Summary: Xft Crash while loading page with MS .fon font [@ GetNormalLineHeight] → Xft Crash while loading page with MS .fon font - FF10PR1 [@ GetNormalLineHeight]
*** Bug 263147 has been marked as a duplicate of this bug. ***
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?
(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.
> 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...
Attached patch patchSplinter Review
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.
Attachment #161996 - Flags: superreview?(blizzard)
Attachment #161996 - Flags: review?(dbaron)
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.
Attachment #161996 - Flags: review?(dbaron) → review+
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?
Attachment #161996 - Flags: superreview?(blizzard) → superreview+
Comment on attachment 161996 [details] [diff] [review]
patch

checked into trunk; requesting branch approvals
Attachment #161996 - Flags: approval1.7.x?
Attachment #161996 - Flags: approval-aviary?
Assignee: dbaron → bryner
Comment on attachment 161996 [details] [diff] [review]
patch

a=chofmann for the branches
Attachment #161996 - Flags: approval1.7.x?
Attachment #161996 - Flags: approval1.7.x+
Attachment #161996 - Flags: approval-aviary?
Attachment #161996 - Flags: approval-aviary+
checked in everywhere
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
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.
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
*** Bug 266184 has been marked as a duplicate of this bug. ***
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.
 
Summary: Xft Crash while loading page with MS .fon font - FF10PR1 [@ GetNormalLineHeight] → Xft Crash while loading page with MS .fon font - FF10RC2 [@ GetNormalLineHeight]
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.
(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?
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.
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.
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.
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.
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.)
Attachment #169524 - Attachment is obsolete: true
Assignee: bryner → dbaron
Status: REOPENED → NEW
Whiteboard: [patch]
Attachment #169525 - Flags: superreview?(bryner)
Attachment #169525 - Flags: review?(bryner)
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.
(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.)
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.)
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.
Attachment #169525 - Attachment description: patch that fixes crash in comment 96 → patch that fixes crash when fc.cache-1 files have entries for fonts that no longer exist
Attachment #169525 - Flags: superreview?(bryner)
Attachment #169525 - Flags: review?(bryner)
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.)
Attachment #169525 - Attachment is obsolete: true
Attachment #169534 - Flags: superreview?(bryner)
Attachment #169534 - Flags: review?
Attachment #169534 - Flags: review? → review?(bryner)
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.
*** Bug 272223 has been marked as a duplicate of this bug. ***
Attachment #169534 - Flags: superreview?(bryner)
Attachment #169534 - Flags: superreview+
Attachment #169534 - Flags: review?(bryner)
Attachment #169534 - Flags: review+
Attachment #169534 - Flags: approval1.7.6?
Attachment #169534 - Flags: approval-aviary1.0.1?
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).
Status: NEW → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
*** Bug 262246 has been marked as a duplicate of this bug. ***
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.
Attachment #169534 - Flags: approval1.7.6?
Attachment #169534 - Flags: approval1.7.6+
Attachment #169534 - Flags: approval-aviary1.0.1?
Attachment #169534 - Flags: approval-aviary1.0.1+
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.
This appears to have caused bug 282453; the XFT code still crashes if it can't
find a valid font.
No longer blocks: 183729
*** Bug 183729 has been marked as a duplicate of this bug. ***
Summary: Xft Crash while loading page with MS .fon font - FF10RC2 [@ GetNormalLineHeight] → Xft Crash while loading page with MS .fon font or read-protected font - FF10RC2 [@ GetNormalLineHeight]
*** Bug 207197 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
No longer blocks: majorbugs
*** Bug 260305 has been marked as a duplicate of this bug. ***
*** Bug 312109 has been marked as a duplicate of this bug. ***
*** Bug 273936 has been marked as a duplicate of this bug. ***
Crash Signature: [@ GetNormalLineHeight]
You need to log in before you can comment on or make changes to this bug.