Closed Bug 183729 Opened 22 years ago Closed 18 years ago

Segmentation fault in XftLockFace (.ttf files need to be world-readable)

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jensus, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: crash, fixed1.8.0.4, fixed1.8.1, Whiteboard: [patch])

Attachments

(4 files, 3 obsolete files)

check return
4.73 KB, patch
blizzard
: review+
roc
: superreview+
Details | Diff | Splinter Review
trace
12.85 KB, text/plain
Details
stack traces
11.44 KB, text/plain
Details
make sure FT_Face is not null
4.91 KB, patch
bryner
: review+
bryner
: superreview+
bryner
: approval-branch-1.8.1+
dveditz
: approval1.8.0.4+
Details | Diff | Splinter Review 
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:
Severity: major → critical
Keywords: crash
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
Assignee: asa → 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?
Blocks: xft_tracking
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: Segmentation fault in XftLockFace → Segmentation fault in XftLockFace (.ttf files need to be world-readable)
*** 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. ***
Attached patch check return — — Splinter Review 
fwiw this also affects freebsd according to
http://lists.freebsd.org/pipermail/freebsd-bugs/2003-April/000238.html
Attachment #129087 - Flags: review?(blizzard)
*** 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?
Flags: blocking1.5b?
not going to block on this for 1.5a since our stock builds aren't impacted.
Flags: blocking1.5b? → blocking1.5b-
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' :-) ?
Component: Browser-General → GFX: Gtk
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
Attachment #129087 - Flags: review?(blizzard) → review+
QA Contact: asa
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.
Attachment #129087 - Flags: superreview?(roc)
Attachment #129087 - Flags: superreview?(roc) → superreview+
patch landed
forgot to mark as resolved/fixed
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → 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.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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?
Attached file trace — 
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.
Attached patch patch (obsolete) — — Splinter Review 
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.
Attachment #140181 - Attachment is obsolete: true
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.
Depends on: 180309
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 ***
Status: REOPENED → RESOLVED
Closed: 21 years ago → 19 years ago
No longer depends on: 180309
Resolution: --- → DUPLICATE
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 ...)
Attachment #140288 - Flags: review?(dbaron)
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.
Attachment #140288 - Flags: review?(dbaron) → review-
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.
Attachment #140288 - Flags: review- → review+
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 331077 has been marked as a duplicate of this bug. ***
jshin's patch merged to trunk
Assignee: blizzard → dbaron
Attachment #140288 - Attachment is obsolete: true
Status: REOPENED → ASSIGNED
Attachment #217599 - Flags: review+
Attachment #217599 - Flags: superreview?(bryner) → superreview+
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...
Attachment #217599 - Flags: review+ → review-
Actually, lets just null-check the things that are known to potentially return null.
Attachment #217599 - Attachment is obsolete: true
Attachment #217629 - Flags: superreview?(bryner)
Attachment #217629 - Flags: review?(vladimir)
Attachment #217629 - Flags: approval-branch-1.8.1?(bryner)
Attachment #217629 - Flags: superreview?(bryner)
Attachment #217629 - Flags: superreview+
Attachment #217629 - Flags: approval-branch-1.8.1?(bryner)
Attachment #217629 - Flags: approval-branch-1.8.1+
Comment on attachment 217629 [details] [diff] [review]
make sure FT_Face is not null

bryner, could you change your sr to an r+sr?
Attachment #217629 - Flags: review?(vladimir) → review?(bryner)
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.
Attachment #217629 - Flags: approval1.8.0.3?
Attachment #217629 - Flags: review?(bryner) → review+
Checked in to trunk and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → FIXED
Blocks: 331077
Comment on attachment 217629 [details] [diff] [review]
make sure FT_Face is not null

approved for 1.8.0 branch, a=dveditz for drivers.
Attachment #217629 - Flags: approval1.8.0.3? → approval1.8.0.3+
Fix checked in to MOZILLA_1_8_0_BRANCH.
Keywords: fixed1.8.0.3, fixed1.8.1
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: