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

RESOLVED FIXED

Status

Core Graveyard
GFX: Gtk
--
critical
RESOLVED FIXED
15 years ago
9 years ago

People

(Reporter: Jens, Assigned: dbaron)

Tracking

({crash, fixed1.8.0.4, fixed1.8.1})

Trunk
x86
Linux
crash, fixed1.8.0.4, fixed1.8.1
Dependency tree / graph
Bug Flags:
blocking1.5b -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch], URL)

Attachments

(4 attachments, 3 obsolete attachments)

(Reporter)

Description

15 years ago
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:

Updated

15 years ago
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 ?)
(Reporter)

Comment 2

15 years ago
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

15 years ago
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: 172768

Comment 5

15 years ago
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

15 years ago
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?

Comment 8

15 years ago
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.

Comment 10

15 years ago
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

15 years ago
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. ***

Comment 13

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

Comment 14

15 years ago
>> 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. ***

Comment 16

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

Comment 17

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

Comment 18

15 years ago
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. ***

Comment 22

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

Comment 23

14 years ago
*** Bug 212942 has been marked as a duplicate of this bug. ***
*** Bug 213819 has been marked as a duplicate of this bug. ***

Comment 25

14 years ago
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

Updated

14 years ago
Attachment #129087 - Flags: review?(blizzard)

Comment 26

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

Comment 27

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

Comment 28

14 years ago
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

14 years ago
'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?

Comment 30

14 years ago
not going to block on this for 1.5a since our stock builds aren't impacted.
Flags: blocking1.5b? → blocking1.5b-
(Assignee)

Comment 31

14 years ago
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

14 years ago
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

14 years ago
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

Comment 34

14 years ago
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+

Updated

14 years ago
QA Contact: asa

Comment 36

14 years ago
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

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

Comment 38

14 years ago
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+

Comment 39

14 years ago
patch landed

Comment 40

14 years ago
forgot to mark as resolved/fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 14 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. ***

Comment 44

14 years ago
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. 
(Assignee)

Comment 45

14 years ago
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 → ---

Comment 46

14 years ago
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

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

Comment 48

14 years ago
*** Bug 230689 has been marked as a duplicate of this bug. ***
*** Bug 230792 has been marked as a duplicate of this bug. ***

Comment 50

14 years ago
would someone please post a stack trace?

Comment 51

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

Comment 52

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

Comment 53

14 years ago
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?
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

14 years ago
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

14 years ago
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.
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
Created attachment 140258 [details]
stack traces

Comment 59

14 years ago
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

14 years ago
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

14 years ago
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.
Attachment #140181 - Attachment is obsolete: true
(Assignee)

Comment 62

14 years ago
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.

Comment 64

14 years ago
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

14 years ago
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. ***

Comment 67

13 years ago
*** Bug 262107 has been marked as a duplicate of this bug. ***
*** Bug 263422 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 69

13 years ago
I think bug 180309 covers the issues for which this was reopened.
Depends on: 180309
(Assignee)

Comment 70

13 years ago
Hopefully fixed by most recent fix to bug 180309.
*** Bug 277735 has been marked as a duplicate of this bug. ***

Comment 72

13 years ago
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

13 years ago
*** Bug 271825 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 74

13 years ago
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.
(Assignee)

Comment 75

13 years ago
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
Last Resolved: 14 years ago13 years ago
No longer depends on: 180309
Resolution: --- → DUPLICATE

Comment 76

12 years ago
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)
(Assignee)

Comment 77

12 years ago
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-
(Assignee)

Comment 78

12 years ago
I'd much rather it be done there, though...
(Assignee)

Comment 79

12 years ago
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+
(Assignee)

Updated

12 years ago
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Comment 80

12 years ago
*** Bug 331077 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 81

12 years ago
Created attachment 217599 [details] [diff] [review]
patch : make sure FT_Face is not null

jshin's patch merged to trunk
Assignee: blizzard → dbaron
Attachment #140288 - Attachment is obsolete: true
Status: REOPENED → ASSIGNED
Attachment #217599 - Flags: review+
(Assignee)

Updated

12 years ago
Whiteboard: [patch]
(Assignee)

Updated

12 years ago
Attachment #217599 - Flags: superreview?(bryner)
Attachment #217599 - Flags: superreview?(bryner) → superreview+
(Assignee)

Comment 82

12 years ago
gfxPangoFont::GetMetrics presumably needs similar changes...
(Assignee)

Comment 83

12 years ago
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-
(Assignee)

Comment 84

12 years ago
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.
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+
(Assignee)

Comment 85

11 years ago
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)
(Assignee)

Comment 86

11 years ago
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+
(Assignee)

Comment 87

11 years ago
Checked in to trunk and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago11 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+
(Assignee)

Comment 89

11 years ago
Fix checked in to MOZILLA_1_8_0_BRANCH.
Keywords: fixed1.8.0.3, fixed1.8.1
Duplicate of this bug: 261543
Duplicate of this bug: 347090
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.