Last Comment Bug 183729 - Segmentation fault in XftLockFace (.ttf files need to be world-readable)
: Segmentation fault in XftLockFace (.ttf files need to be world-readable)
Status: RESOLVED FIXED
[patch]
: crash, fixed1.8.0.4, fixed1.8.1
Product: Core Graveyard
Classification: Graveyard
Component: GFX: Gtk (show other bugs)
: Trunk
: x86 Linux
: -- critical with 4 votes (vote)
: ---
Assigned To: David Baron :dbaron: ⌚️UTC-10
:
:
Mentors:
http://themes.mozdev.org/themes/early...
: 184405 196281 197635 201878 201960 203350 207773 211720 212418 212942 213819 215132 216095 218691 221065 223224 228783 230239 230689 230792 231462 255856 261543 262107 263422 271825 277735 347090 (view as bug list)
Depends on:
Blocks: xft_tracking 331077
  Show dependency treegraph
 
Reported: 2002-12-05 07:44 PST by Jens
Modified: 2009-01-22 10:17 PST (History)
34 users (show)
asa: blocking1.5b-
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
check return (4.73 KB, patch)
2003-08-03 00:14 PDT, timeless
blizzard: review+
roc: superreview+
Details | Diff | Splinter Review
trace (12.85 KB, text/plain)
2004-01-29 11:18 PST, Christian Persch (GNOME) (away; not receiving bug mail)
no flags Details
patch (2.87 KB, patch)
2004-01-29 12:54 PST, Jungshik Shin
no flags Details | Diff | Splinter Review
stack traces (11.44 KB, text/plain)
2004-01-30 14:06 PST, Christian Persch (GNOME) (away; not receiving bug mail)
no flags Details
patch : make sure FT_Face is not null (3.96 KB, patch)
2004-01-30 21:06 PST, Jungshik Shin
dbaron: review+
Details | Diff | Splinter Review
patch : make sure FT_Face is not null (4.60 KB, patch)
2006-04-07 13:09 PDT, David Baron :dbaron: ⌚️UTC-10
dbaron: review-
bryner: superreview+
Details | Diff | Splinter Review
make sure FT_Face is not null (4.91 KB, patch)
2006-04-07 16:25 PDT, David Baron :dbaron: ⌚️UTC-10
bryner: review+
bryner: superreview+
bryner: approval‑branch‑1.8.1+
dveditz: approval1.8.0.4+
Details | Diff | Splinter Review

Description Jens 2002-12-05 07:44:24 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021205

When viewing some pages like http://themes.mozdev.org/themes/earlyblue.html
and http://www.zvon.org/ mozilla crashes.


#0  0x40aef885 in XftLockFace () from /home/jens/garnome/lib/libXft.so.2
#1  0x40abefba in NSGetModule () from /usr/local/mozilla/components/libgfx_gtk.so
#2  0x40abef64 in NSGetModule () from /usr/local/mozilla/components/libgfx_gtk.so
#3  0x40abe40a in NSGetModule () from /usr/local/mozilla/components/libgfx_gtk.so
#4  0x400271cf in nsFontCache::GetMetricsFor () from /usr/local/mozilla/libgkgfx.so
#5  0x4002627e in DeviceContextImpl::GetMetricsFor () from
/usr/local/mozilla/libgkgfx.so
#6  0x40a9ec87 in NSGetModule () from /usr/local/mozilla/components/libgfx_gtk.so
#7  0x41168a36 in NSGetModule () from /usr/local/mozilla/components/libgklayout.so
...
lots of calls to NSGetModule 
...
#78 0x411b0893 in NSGetModule () from /usr/local/mozilla/components/libgklayout.so
#79 0x401848c1 in PL_HandleEvent () from /usr/local/mozilla/libxpcom.so
#80 0x401847c9 in PL_ProcessPendingEvents () from /usr/local/mozilla/libxpcom.so
#81 0x401858bb in nsEventQueueImpl::ProcessPendingEvents () from
/usr/local/mozilla/libxpcom.so
#82 0x40d7b7bd in NSGetModule () from /usr/local/mozilla/components/libwidget_gtk.so
#83 0x40d7b506 in NSGetModule () from /usr/local/mozilla/components/libwidget_gtk.so
#84 0x403a4c90 in g_io_unix_dispatch (source_data=0x816bda0,
current_time=0xbffff444, user_data=0x823ff50) at giounix.c:135
#85 0x403a6358 in g_main_dispatch (dispatch_time=0xbffff444) at gmain.c:656
#86 0x403a6963 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#87 0x403a6afc in g_main_run (loop=0x823ff90) at gmain.c:935
#88 0x402c87b7 in gtk_main () at gtkmain.c:524
#89 0x40d7bc2e in NSGetModule () from /usr/local/mozilla/components/libwidget_gtk.so
#90 0x415d6c88 in nsldapi_ld_defaults () from
/usr/local/mozilla/components/libnsappshell.so
#91 0x080526e0 in getCountry ()
#92 0x0805305b in main ()


Reproducible: Always

Steps to Reproduce:
Comment 1 Matthias Versen [:Matti] 2002-12-05 08:28:02 PST
Do you use a XFT enabled build ?
(if yes:  Why can't I see a comment about this in this report ?)
Comment 2 Jens 2002-12-05 08:37:09 PST
Here are the buildoptions

ac_add_options --disable-mailnews
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize
ac_add_options --enable-cpp-rtti
ac_add_options --enable-strip-libs
ac_add_options --without-jpeg
ac_add_options --without-zlib
ac_add_options --without-png
ac_add_options --enable-mathml
ac_add_options --enable-crypto
ac_add_options --enable-xft
Comment 3 Andrew Schultz 2002-12-05 20:14:08 PST
worksforme with linux/xft trunk
if you still have your source tree, can you just recompile the 'gfx' directory
with symbols?  it would help a lot.

==> blizzard
Comment 4 Christopher Blizzard (:blizzard) 2002-12-06 08:11:22 PST
Well, it's working here.  Can you do an NSPR_LOG_MODULES=XftFontLoad:5 on those
pages and let me know what the output is right before the crash?
Comment 5 Pete Chapman 2003-02-22 08:42:33 PST
I am getting this crash too, with the "mozilla-1.2.1-4mdk.i586.rpm" package.
XftLockFace() is being passed a null pointer for some reason, but since I'm not 
building from source I can't tell why...
Comment 6 Pete Chapman 2003-02-22 16:13:54 PST
I've built a debug mozilla from mozilla-1.2.1-4mdk.i586.src.rpm. Here is the stack 
trace:

#0  0x410fd8fd in XftLockFace () from /usr/X11R6/lib/libXft.so.1
#1  0x410b31d8 in nsFontMetricsXft::CacheFontMetrics() (this=0x8632db0) at 
nsFontMetricsXft.cpp:760
#2  0x410b316f in nsFontMetricsXft::RealizeFont() (this=0x8632db0) at 
nsFontMetricsXft.cpp:744
#3  0x410b24f8 in nsFontMetricsXft::Init(nsFont const&, nsIAtom*, 
nsIDeviceContext*) (this=0x8632db0, aFont=@0x89f35d0, 
aLangGroup=0x83fc300, aContext=0x864b218) at nsFontMetricsXft.cpp:267
#4  0x400372b8 in nsFontCache::GetMetricsFor(nsFont const&, nsIAtom*, 
nsIFontMetrics*&) (this=0x856cd00, aFont=@0x89f35d0, 
aLangGroup=0x83fc300, aMetrics=@0xbfffabe0) at nsDeviceContext.cpp:669
#5  0x400362b3 in DeviceContextImpl::GetMetricsFor(nsFont const&, nsIAtom*, 
nsIFontMetrics*&) (this=0x864b218, aFont=@0x89f35d0, 
aLangGroup=0x83fc300, aMetrics=@0xbfffabe0) at nsDeviceContext.cpp:344
#6  0x41dd9d6b in ComputeLineHeight (aPresContext=0x85657c0, 
aRenderingContext=0x8864b10, aStyleContext=0x8983ce4) at 
nsHTMLReflowState.cpp:2341


And this is where it's going wrong, in
mozilla/gfx/src/gtk/nsFontMetricsXft.cpp:

    747 nsresult
    748 nsFontMetricsXft::CacheFontMetrics(void)
    749 {
    750     // Get our scale factor
    751     float f;
    752     float val;
    753     mDeviceContext->GetDevUnitsToAppUnits(f);
    754 
    755     // Get our font face
    756     FT_Face face;
    757     TT_OS2 *os2;
    758     XftFont *xftFont = mWesternFont->GetXftFont();
    759 
    760     face = XftLockFace(xftFont);

The problem is on line 760, where XftLockFace is being called with a null 
pointer. There are other points in that file where nsFontXft::GetXftFont() is 
assumed not to return null too. On my system this assumption is wrong! This is 
the first time I've looked at this file, so deeper analysis is beyond me at the 
moment.

I built with these options:

./configure --enable-xft --enable-debug --disable-strip --disable-mailnews 
--disable-calendar --enable-crypto --disable-composer --disable-installer
Comment 7 Christopher Blizzard (:blizzard) 2003-02-22 19:32:17 PST
Do you have .fon files in your path?
Comment 8 Pete Chapman 2003-02-23 09:24:55 PST
Christopher: no, I don't have any .fon files on my system. But I do have .ttf
files imported from a Windows partition.

Repeating this crash with a debug version of libXft.so, I find that
nsFontXft::GetXftFont is returning 0 when looking at the following .ttf file:

/usr/X11R6/lib/X11/fonts/drakfont/ttf/verdana.ttf

The cause of this is a call to FT_New_Face failing, here:

FT_New_Face
in _XftLockFile (xftfreetype.c:159)
in XftFontOpenInfo (xftfreetype.c:670)
in XftFontOpenPattern (xftfreetype.c:915)
in nsFontXft::GetXftFont (nsFontMetricsXft.cpp:1580)

I removed the verdana.ttf file outside of my font path, and Mozilla stopped
crashing! Unfortunately, when I moved the font BACK again I could no longer
recreate the crash (is font information cached?)

So it is quite possible that the crash was brought on by a buggy ttf file,
however I think that Mozilla should handle the case where the library call to
XftFontOpenPattern returns 0, rather than crashing. If verdana.ttf is broken
then the Xft library is behaving correctly, we just need to be more careful in
dealing with the return value.
Comment 9 Christopher Blizzard (:blizzard) 2003-02-23 09:55:20 PST
Is it possible that as the user you are running mozilla as you can not read the
.ttf file?  I'm just curious so I can set up tests.

fwiw, I agree that this is a case that needs to be handled.
Comment 10 Pete Chapman 2003-02-23 10:39:34 PST
Yes! You're absolutely right, some of my ttf files have permissions 755, others have 
440 (including verdana). I hadn't noticed that before, and have no idea how it 
happened.

I didn't know that fonts needed to be world-readable, but I'll change them now. 
Unfortunately I can't recreate the bug, so I can't tell you whether that would have 
fixed the problem!
Comment 11 Pete Chapman 2003-02-23 14:54:16 PST
OK, after restarting and deleting ~/.mozilla, I can recreate the crash at any time 
by doing:
chmod o-r *.ttf
in my fonts directory.

I think those permissions were funny because they were automatically copied 
from a windows partition mounted with a restrictive umask - perhaps one for the 
drakfont developers?

Thanks for your help.
Comment 12 Christopher Blizzard (:blizzard) 2003-02-23 20:19:26 PST
*** Bug 184405 has been marked as a duplicate of this bug. ***
Comment 13 Frederic Crozat 2003-02-24 01:18:51 PST
This is a bug in fontconfig, which fails when fonts are not readable :(
Comment 14 Pete Chapman 2003-02-24 02:37:11 PST
>> This is a bug in fontconfig, which fails when fonts are not readable :(

I'm not familiar with the fontconfig library, so I don't know whether the failure is correct behaviour under these conditions. But at least it fails cleanly!

Surely there is (also) a bug in Mozilla because Mozilla does not handle the failure?
Comment 15 Christopher Blizzard (:blizzard) 2003-03-07 07:42:28 PST
*** Bug 196281 has been marked as a duplicate of this bug. ***
Comment 16 eger 2003-03-15 22:01:07 PST
*** Bug 197635 has been marked as a duplicate of this bug. ***
Comment 17 Andrew Schultz 2003-04-14 10:56:22 PDT
*** Bug 201878 has been marked as a duplicate of this bug. ***
Comment 18 Parveen Kaler 2003-04-14 11:40:10 PDT
I'm seeing something similiar (Bug 201878).  I recently installed FreeType
version 2.1.4.  My fonts look a whole lot perttyer though.
Comment 19 Christian :Biesinger (don't email me, ping me on IRC) 2003-05-31 14:34:32 PDT
*** Bug 207773 has been marked as a duplicate of this bug. ***
Comment 20 Matthias Versen [:Matti] 2003-07-04 10:05:01 PDT
*** Bug 211720 has been marked as a duplicate of this bug. ***
Comment 21 Christopher Blizzard (:blizzard) 2003-07-07 10:47:14 PDT
*** Bug 203350 has been marked as a duplicate of this bug. ***
Comment 22 Olivier Cahagne 2003-07-11 09:48:57 PDT
*** Bug 212418 has been marked as a duplicate of this bug. ***
Comment 23 Marco Pesenti Gritti 2003-07-18 14:29:54 PDT
*** Bug 212942 has been marked as a duplicate of this bug. ***
Comment 24 Christopher Blizzard (:blizzard) 2003-07-25 11:56:17 PDT
*** Bug 213819 has been marked as a duplicate of this bug. ***
Comment 25 timeless 2003-08-03 00:14:36 PDT
Created attachment 129087 [details] [diff] [review]
check return

fwiw this also affects freebsd according to
http://lists.freebsd.org/pipermail/freebsd-bugs/2003-April/000238.html
Comment 26 Andrew Schultz 2003-08-11 16:32:08 PDT
*** Bug 215132 has been marked as a duplicate of this bug. ***
Comment 27 Andrew Schultz 2003-08-13 18:08:43 PDT
*** Bug 216095 has been marked as a duplicate of this bug. ***
Comment 28 Christian Hamacher 2003-08-14 01:29:51 PDT
I'm the reporter of bug 216095, which has just been duped to this bug. In my
case, the reason for the crash was not restrictive permissions, but rather
dangling links: I had linked a bunch of TTF fonts from my windows partition into
my Linux font directory, and promptly forgotten about it.

Later, I updated my Windows version on that partition - in the process of doing
that, some fonts disappeared, and left the links dangling. Everything was fine
until I visited www.zeit.de, which seems to use at least one of the 'missing'
fonts -> Crash!
Comment 29 Christian Hamacher 2003-08-14 02:06:30 PDT
'blocking1.5b'->?

On the one hand, this can potentially affect many Linux users, since a lot of
the popular distributions (RH, Mandrake, Gentoo, possibly Debian, ...) are
shipping Xft-enabled Mozilla builds, and permission problems when mounting
Windows partitions as sources for TTF fonts seem to be common. For the user,
debugging problems like this is difficult, since they are hard to reproduce: you
can have two identical Linux installations, one of them crashing (if the Win
partition contains a certain font, but it's unreadable) and the other not
crashing (if the font isn't installed under Windows). Judging from the number of
duplicates, this problem is quite common, and it happens (e.g. in the case of
www.zeit.de) on high-profile sites.

On the other hand, there is a patch by timeless available, which simply adds
null checking, and therefore seems quite low-risk to me. 

What do the reviewers/drivers say?
Comment 30 Asa Dotzler [:asa] 2003-08-14 11:27:34 PDT
not going to block on this for 1.5a since our stock builds aren't impacted.
Comment 31 David Baron :dbaron: ⌚️UTC-10 2003-08-14 11:28:40 PDT
Comment on attachment 129087 [details] [diff] [review]
check return

This pattern could be:

>-    if (!mXftFont)
>-        GetXftFont();
>+    if (!mXftFont && !GetXftFont())
>+        return NS_ERROR_NOT_AVAILABLE;

(I haven't looked at this in more detail, though.)
Comment 32 Christian Hamacher 2003-08-15 06:26:59 PDT
Re #30:
Yes, I'll have to follow that logic - my 'blocking' request was a bit overzealous.

Would timeless' null checks meet the drivers' criterion of being 'low risk'
enough for checkin into the branch (provided that patch passes r/sr)?
Comment 33 Jungshik Shin 2003-08-16 03:14:16 PDT
dbaron's pattern should work fine(comment #31). I agree with Christian (comment
#29) that this bug will affect a lot of Linux users. Let's get this fixed before
1.5f. blizzard, why don't you 'triple' as 'r,sr and a1.5b' :-) ? 
Comment 34 Jungshik Shin 2003-09-06 11:05:29 PDT
blizzard, can you move this forward (before 1.5. and also in 1.4.1/2)?  With
dbaron's change in comment #31, the patch should be fine, shouldn't it?

Although the default linux binary build is not affected,  realistically who's
gonna use the default build on Linux when gtk2+Xft build with 'hundred times'
better rendering quality is available?  
Comment 35 Christopher Blizzard (:blizzard) 2003-09-19 08:45:49 PDT
Comment on attachment 129087 [details] [diff] [review]
check return

r=blizzard
Comment 36 eger 2003-10-05 04:58:01 PDT
patch works for me; I'm currently encountering this bug and all of the ttf files
on my system *are* world readable. it is very strange.
Comment 37 Olivier Cahagne 2003-10-22 13:18:42 PDT
*** Bug 223224 has been marked as a duplicate of this bug. ***
Comment 38 Jungshik Shin 2003-10-22 23:19:05 PDT
Comment on attachment 129087 [details] [diff] [review]
check return

To move things forward, i'm asking for sr. I'll check this in with the change
suggested by dbaron in comment #31 iftimeless is not going to.
Comment 39 Jungshik Shin 2003-10-29 21:48:45 PST
patch landed
Comment 40 Jungshik Shin 2003-11-01 16:40:58 PST
forgot to mark as resolved/fixed
Comment 41 Christopher Blizzard (:blizzard) 2003-11-05 06:18:21 PST
*** Bug 201960 has been marked as a duplicate of this bug. ***
Comment 42 Christopher Blizzard (:blizzard) 2003-11-10 10:26:54 PST
*** Bug 221065 has been marked as a duplicate of this bug. ***
Comment 43 Christopher Blizzard (:blizzard) 2003-12-04 07:44:01 PST
*** Bug 218691 has been marked as a duplicate of this bug. ***
Comment 44 Aaron Vinson 2004-01-05 08:01:01 PST
This bug still exists. I've tried with the latest nightly Firebird build. Using
a debuggable libXft I got very similar messages to the XftLockFact in libXft
error described in this bug. An strace reveals that Firebird is dying when
attempting to open a font (on http://www.pridefc.com/) that's not present:

open("/usr/share/fonts/ja/TrueType/kochi-mincho.ttf", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/share/fonts/ja/TrueType/kochi-mincho.ttf", O_RDONLY) = -1 ENOENT (No
such file or directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
unlink("/root/.phoenix/default/5odkgce4.slt/lock") = 0
exit_group(11)

here's an 'ls -la' of my /usr/share/fonts/ja/TrueType/:

-rw-r--r--    1 root     root         1548 Aug 11 05:34 fonts.alias
-rw-r--r--    1 root     root        16674 Nov 11 09:22 fonts.cache-1
-rw-r--r--    1 root     root         7285 Nov 11 09:22 fonts.dir
-rw-r--r--    1 root     root         7285 Nov 11 09:22 fonts.scale
-rw-r--r--    1 root     root      7770652 Aug 11 05:34 kochi-gothic-subst.ttf
-rw-r--r--    1 root     root        17318 Aug 11 05:34 kochi-gothic-subst.tti
-rw-r--r--    1 root     root      8967464 Aug 11 05:34 kochi-mincho-subst.ttf
-rw-r--r--    1 root     root        17318 Aug 11 05:34 kochi-mincho-subst.tti

I don't know enough about fontconfig to understand why Firebird is doing what
it's doing, but I can say that the patch attached here *does not* resolve the
specific issue I'm experiencing. 
Comment 45 David Baron :dbaron: ⌚️UTC-10 2004-01-05 08:43:44 PST
Yeah, I've seen this as well -- and while the stack is different, the bug is not
fixed.

See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111973 for an
explanation of what's happening with fontconfig, though.  (This leads to a
workaround, which is to uninstall ttfonts-ja and then reinstall it.)
Comment 46 Jungshik Shin 2004-01-05 09:40:58 PST
I'm wondering what we can do on mozilla's side until the issue reported in
Redhat bugzilla is resolved in fontconfig. I've just filed a bug at freedesktop
bugzilla.
(http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=166)
Comment 47 Andrew Schultz 2004-01-06 14:09:04 PST
*** Bug 230239 has been marked as a duplicate of this bug. ***
Comment 48 Olivier Cahagne 2004-01-12 07:08:28 PST
*** Bug 230689 has been marked as a duplicate of this bug. ***
Comment 49 Matthias Versen [:Matti] 2004-01-13 07:17:03 PST
*** Bug 230792 has been marked as a duplicate of this bug. ***
Comment 50 timeless 2004-01-14 19:00:10 PST
would someone please post a stack trace?
Comment 51 Olivier Cahagne 2004-01-19 05:05:34 PST
*** Bug 231462 has been marked as a duplicate of this bug. ***
Comment 52 Olivier Cahagne 2004-01-20 07:30:08 PST
*** Bug 228783 has been marked as a duplicate of this bug. ***
Comment 53 Aaron Vinson 2004-01-29 09:08:53 PST
Could you clarify what you mean by stack trace and explain how to perform one?
I'm unfamiliar with the C debugging process. Are you referring to the gdb output
when using a debug enabled libXft?
Comment 54 Christian Persch (GNOME) (away; not receiving bug mail) 2004-01-29 11:18:57 PST
Created attachment 140178 [details]
trace

Here's the trace I got from my debug build (to correlate the line numbers:
built from cvs checkout from 2004-01-10).
Comment 55 Jungshik Shin 2004-01-29 12:23:18 PST
According to the stack trace, it crashes at line 909: 

http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsXft.cpp#909
908     // mUnderlineOffset (offset for underlines)
909     val = CONVERT_DESIGN_UNITS_TO_PIXELS(face->underline_position,
910                                          face->size->metrics.y_scale);

It seems like face or face->size is null for some reason. face is obtained here:


844     XftFont *xftFont = mWesternFont->GetXftFont();
845     if (!xftFont)
846         return NS_ERROR_NOT_AVAILABLE;
847 
848     face = XftLockFace(xftFont);
849     os2 = (TT_OS2 *) FT_Get_Sfnt_Table(face, ft_sfnt_os2);

So, we have to check if face or face->size is null. 
Comment 56 Jungshik Shin 2004-01-29 12:54:19 PST
Created attachment 140181 [details] [diff] [review]
patch

Christian, can you try this? I can't test it because I can't reproduce the
crash.

BTW, we may just have to return with an error code if 'face' is null.
Comment 57 Christian Persch (GNOME) (away; not receiving bug mail) 2004-01-30 14:02:51 PST
Btw, it is "face" that's null (looked at it in gdb.)

With the patch from attachment id=140181 applied, I no longer get the crash with
the trace from attachment id=140178.
However, with or without the patch, I repeatedly got crashes with the traces I'm
going to attach (2 different traces) -- not sure if it's the same bug or a
different problem. (build is now from cvs 2004-01-30).

Also, I get multiple "Xft: locking error too many file unlocks" messages.

Steps I use to reproduce in TestGtkEmbed:
1) browse a bit
2) chmod go-r all your fonts
3) continue to browse
4) eventually crash
Comment 58 Christian Persch (GNOME) (away; not receiving bug mail) 2004-01-30 14:06:27 PST
Created attachment 140258 [details]
stack traces
Comment 59 Jungshik Shin 2004-01-30 18:32:19 PST
The crash in attachment 140258 [details] is occuring here:
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsHTMLReflowState.cpp#2146

2144 GetNormalLineHeight(nsIFontMetrics* aFontMetrics)
2145 {
2146   NS_PRECONDITION(nsnull != aFontMetrics, "no font metrics");
....
2169 #else
2170   aFontMetrics->GetNormalLineHeight(normalLineHeight);
2171 #endif // FONT_LEADING_APIS_V2

In an optimized build, NS_PRECONDITION is no-op. If |aFontMetrics| is null, we
have to bail out earlier, but we apparently don't. I recall there's a bug
related to this ...

BTW, can you attach the other trace you mentioned, Christian? 

> Also, I get multiple "Xft: locking error too many file unlocks" messages.

  Under what condition? With or without the patch applied? Or, did you get this
message only after making all your font unreadable (chmod go-r)? 
Comment 60 Jungshik Shin 2004-01-30 18:43:25 PST
I guess you got the 'unlock-related' message with the patch applied. I should
have checked 'face' before calling XftUnlockFace. Now I'm wondering when/why
XftLockFace fails. Aha...that's described in comment #44 and comment #45. In
that case, we don't have to bother to fall back and we just have to return early
with an error code. I'll upload a patch later (I have to run now)

Comment 61 Jungshik Shin 2004-01-30 21:06:06 PST
Created attachment 140288 [details] [diff] [review]
patch : make sure FT_Face is not null

If face->size is guaranteed to be valid (as far as face is valid), I can get
rid of the second chunk in this patch. 

Keith, is it the case? 

BTW, this wouldn't fix the crash in attaachment 140258 because |nsIFontMetrics|
is not checked for null in layout. Actually, I'm not sure what it can do other
than dying if |nsIFontMetrics| is null.
Comment 62 David Baron :dbaron: ⌚️UTC-10 2004-01-31 00:13:29 PST
I don't think GFX implementations should ever return a null font metrics unless
there are no fonts available (or perhaps on out-of-memory, but probably not even
then).
Comment 63 Christian Persch (GNOME) (away; not receiving bug mail) 2004-01-31 02:36:12 PST
(In reply to comment #59)
> BTW, can you attach the other trace you mentioned, Christian? 
It is in attachment 140258 [details], after the first trace.

> > Also, I get multiple "Xft: locking error too many file unlocks" messages.
> 
>   Under what condition? With or without the patch applied? Or, did you get this
> message only after making all your font unreadable (chmod go-r)? 

With the patch applied, and I saw them only after making the fonts unreadable.
Comment 64 Jungshik Shin 2004-01-31 02:57:53 PST
re: comment #62
Oh, you're right. My latest patch makes |nsIFontMetrics->Init| fail and  return
an error code when 'face' is null (, which can occur in situations as described
in comment #44).  I have little idea why nsIFontMetrics itself is null in
attachment 140258 [details]. 
Comment 65 R.K.Aa. 2004-03-17 11:42:50 PST
Some reports a crash when a requested ttf font does not exist:
bug 225892, bug 237814. Dup of this one?
Comment 66 Mats Palmgren (:mats) 2004-08-17 04:28:57 PDT
*** Bug 255856 has been marked as a duplicate of this bug. ***
Comment 67 Andrew Schultz 2004-10-04 06:55:58 PDT
*** Bug 262107 has been marked as a duplicate of this bug. ***
Comment 68 Matthias Versen [:Matti] 2004-10-08 16:27:13 PDT
*** Bug 263422 has been marked as a duplicate of this bug. ***
Comment 69 David Baron :dbaron: ⌚️UTC-10 2004-10-11 15:29:28 PDT
I think bug 180309 covers the issues for which this was reopened.
Comment 70 David Baron :dbaron: ⌚️UTC-10 2005-01-09 10:35:42 PST
Hopefully fixed by most recent fix to bug 180309.
Comment 71 Matthias Versen [:Matti] 2005-01-10 10:34:11 PST
*** Bug 277735 has been marked as a duplicate of this bug. ***
Comment 72 Martin von Gagern 2005-03-09 11:13:01 PST
WRT comment 69: bug 180309 comment 29 states that these are two different bugs.

I had this bug here today with my thunderbird 1.0. strace showed me that it
tried to access /usr/X11R6/lib/X11/fonts/windows/tahoma.ttf which I had copied
from a NTFS mount and which was mode 0400.

If bug 180309 is indeed the same as this, its subject should be changed to
incluse TTFs as well as FONs.
Comment 73 Martin von Gagern 2005-03-09 11:26:48 PST
*** Bug 271825 has been marked as a duplicate of this bug. ***
Comment 74 David Baron :dbaron: ⌚️UTC-10 2005-03-09 11:53:42 PST
The most recent fix to bug 180309 went in *after* Thunderbird 1.0, so comment 72
does not in any way contradict comment 69 or comment 70.
Comment 75 David Baron :dbaron: ⌚️UTC-10 2005-03-09 12:00:23 PST
I haven't found any comments that suggest this isn't a duplicate.

*** This bug has been marked as a duplicate of 180309 ***
Comment 76 timeless 2006-03-20 09:33:05 PST
Comment on attachment 140288 [details] [diff] [review]
patch : make sure FT_Face is not null

dbaron, bug 331077 comment 0 is a comment claiming this isn't a duplicate (i would rather it have been added to this bug w/ a request to reopen, but ...)
Comment 77 David Baron :dbaron: ⌚️UTC-10 2006-04-07 13:02:23 PDT
Comment on attachment 140288 [details] [diff] [review]
patch : make sure FT_Face is not null

This looks OK, except that you're changing what's checked against 0 -- from design units to pixels.  And something that's nonzero in design units could be zero in pixels -- and for these tiny values, might be.
Comment 78 David Baron :dbaron: ⌚️UTC-10 2006-04-07 13:03:59 PDT
I'd much rather it be done there, though...
Comment 79 David Baron :dbaron: ⌚️UTC-10 2006-04-07 13:06:57 PDT
Comment on attachment 140288 [details] [diff] [review]
patch : make sure FT_Face is not null

Er, oops, I misread the old code; it's not changing that.
Comment 80 David Baron :dbaron: ⌚️UTC-10 2006-04-07 13:08:50 PDT
*** Bug 331077 has been marked as a duplicate of this bug. ***
Comment 81 David Baron :dbaron: ⌚️UTC-10 2006-04-07 13:09:54 PDT
Created attachment 217599 [details] [diff] [review]
patch : make sure FT_Face is not null

jshin's patch merged to trunk
Comment 82 David Baron :dbaron: ⌚️UTC-10 2006-04-07 16:10:07 PDT
gfxPangoFont::GetMetrics presumably needs similar changes...
Comment 83 David Baron :dbaron: ⌚️UTC-10 2006-04-07 16:13:05 PDT
Comment on attachment 217599 [details] [diff] [review]
patch : make sure FT_Face is not null

Actually, null-checking face->size in some places but not others isn't very useful...
Comment 84 David Baron :dbaron: ⌚️UTC-10 2006-04-07 16:25:01 PDT
Created attachment 217629 [details] [diff] [review]
make sure FT_Face is not null

Actually, lets just null-check the things that are known to potentially return null.
Comment 85 David Baron :dbaron: ⌚️UTC-10 2006-04-21 22:09:21 PDT
Comment on attachment 217629 [details] [diff] [review]
make sure FT_Face is not null

bryner, could you change your sr to an r+sr?
Comment 86 David Baron :dbaron: ⌚️UTC-10 2006-04-21 22:14:59 PDT
Comment on attachment 217629 [details] [diff] [review]
make sure FT_Face is not null

This patch is basically just a nullcheck to fix a topcrash, which I should have left on bug 331077, but decided to put here since it's based on jshin's patch here.
Comment 87 David Baron :dbaron: ⌚️UTC-10 2006-04-22 10:50:56 PDT
Checked in to trunk and MOZILLA_1_8_BRANCH.
Comment 88 Daniel Veditz [:dveditz] 2006-04-24 16:42:51 PDT
Comment on attachment 217629 [details] [diff] [review]
make sure FT_Face is not null

approved for 1.8.0 branch, a=dveditz for drivers.
Comment 89 David Baron :dbaron: ⌚️UTC-10 2006-04-24 16:59:05 PDT
Fix checked in to MOZILLA_1_8_0_BRANCH.
Comment 90 Mats Palmgren (:mats) 2007-05-03 19:42:30 PDT
*** Bug 261543 has been marked as a duplicate of this bug. ***
Comment 91 Mats Palmgren (:mats) 2007-06-17 03:35:35 PDT
*** Bug 347090 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.