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:

Do you use a XFT enabled build ? (if yes: Why can't I see a comment about this in this report ?)

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

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

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?

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

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

Do you have .fon files in your path?

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.

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.

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!

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.

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

This is a bug in fontconfig, which fails when fonts are not readable :(

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

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

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

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

I'm seeing something similiar (Bug 201878). I recently installed FreeType version 2.1.4. My fonts look a whole lot perttyer though.

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

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

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

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

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

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

fwiw this also affects freebsd according to http://lists.freebsd.org/pipermail/freebsd-bugs/2003-April/000238.html

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

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

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!

'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?

not going to block on this for 1.5a since our stock builds aren't impacted.

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

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)?

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' :-) ?

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 on attachment 129087 [details] [diff] [review] check return r=blizzard

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.

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

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.

patch landed

forgot to mark as resolved/fixed

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

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

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

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.

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

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)

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

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

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

would someone please post a stack trace?

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

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

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?

Here's the trace I got from my debug build (to correlate the line numbers: built from cvs checkout from 2004-01-10).

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.

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.

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

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)?

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)

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.

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

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

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

Some reports a crash when a requested ttf font does not exist: bug 225892, bug 237814. Dup of this one?

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

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

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

I think bug 180309 covers the issues for which this was reopened.

Hopefully fixed by most recent fix to bug 180309.

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

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.

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

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.

I haven't found any comments that suggest this isn't a duplicate. *** This bug has been marked as a duplicate of 180309 ***

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

I'd much rather it be done there, though...

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.

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

jshin's patch merged to trunk

gfxPangoFont::GetMetrics presumably needs similar changes...

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

Actually, lets just null-check the things that are known to potentially return null.

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

Checked in to trunk and MOZILLA_1_8_BRANCH.

Comment on attachment 217629 [details] [diff] [review] make sure FT_Face is not null approved for 1.8.0 branch, a=dveditz for drivers.

Fix checked in to MOZILLA_1_8_0_BRANCH.