175108 - X_CreatePixmap crash with Xft(2) build using core X fonts on some chars if antialiased

Status: RESOLVED FIXED

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

Description

[Tomas Ögren]

When visiting some web pages (like the one in the url), mozilla crashes with an
X error pointing at X_CreatePixmap.
Actual dump (when running with --sync):
Xlib:  extension "RENDER" missing on display ":0.0".
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  53 (X_CreatePixmap)
  Value in failed request:  0x0
  Serial number of failed request:  7401
  Current serial number in output stream:  7402

Stack trace:
<X wanting to dump>
#8  0xfec9eaac in XCreatePixmap () from /usr/lib/libX11.so.4
#9  0xfd435b58 in XftGlyphFontSpecCore (draw=0x7221f0, color=0xffbedca8, 
    glyphs=0xffbeac20, nglyphs=1) at xftcore.c:1305
#10 0xfd437dc4 in XftDrawGlyphFontSpec (draw=0x7221f0, color=0xffbedca8, 
    glyphs=0xffbeac20, len=1) at xftdraw.c:735
#11 0xfd437f44 in XftDrawCharFontSpec (draw=0x7221f0, color=0xffbedca8, 
    chars=0xfd1f808c, len=1) at xftdraw.c:795
#12 0xfd1c8e70 in NSGetModule ()
   from /scratch/xftmoz/mozilla/components/libgfx_gtk.so
(gdb) frame 9
#9  0xfd435b58 in XftGlyphFontSpecCore (draw=0x7221f0, color=0xffbedca8, 
    glyphs=0xffbeac20, nglyphs=1) at xftcore.c:1305

1305                pix = XCreatePixmap (dpy, draw->drawable,
1306                                     width, height, depth);
(gdb) p depth
$1 = 24
(gdb) p height
$2 = 0
(gdb) p width
$3 = 0

#10 0xfd437dc4 in XftDrawGlyphFontSpec (draw=0x7221f0, color=0xffbedca8, 
    glyphs=0xffbeac20, len=1) at xftdraw.c:735
735                     XftGlyphFontSpecCore (draw, color, glyphs, len);
(gdb) p *glyphs
$15 = {font = 0x321548, glyph = 3, x = 23, y = 22}

The web page consists of "&#x12a0; &#x12a0;", if the space is removed - no
crash. Crashes are seen on various news sites as well. I have not been able to
reproduce with antialiasing off.

Output from fc-list is available at
http://www.cs.umu.se/~stric/tmp/fc-list.output and my font cache is available at
http://www.cs.umu.se/~stric/tmp/fonts.cache-1
Default font is Arial v2.95, 16pt - screen 90dpi
Xft is from fcpackage 2.0 with a patch from Keith sent to the fonts list to stop
it from crashing when reading the cache.
OS: Solaris 8/Sparc
GCC 2.95.2 used to compile both mozilla and fontconfig/Xft

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

->blizzard

Comment 2

[Andrew Schultz]

worksforme with linux trunk / xft build 20021123.  garbage glyphs are displayed,
but no crash.

Comment 3

[Andrew Hagen]

Critical severity.

Comment 4

[Siva Kumar]

Confirmed.
OS: Solaris 8/Sparc
Build: Using Sun Forte 6.2
Workaround: 
In file xftcore.c (under fcpackage/Xft directory), line #1309
changed from
	if (!image && (depth = XftDrawDepth (draw)))
to
	if (!image && (depth = XftDrawDepth (draw)) && width != 0 && height != 0)

Dont know if this is a proper fix, but it doesnt crash with X_CreatePixmap errors.

Comment 5

[Christopher Blizzard (:blizzard)]

Looks like an xft issue.

Comment 6

[keithp]

Oops.  Easy to fix in Xft.

Feel free to try this patch:

Index: xftcore.c
===================================================================
RCS file: /home/x-cvs/xc/lib/Xft/xftcore.c,v
retrieving revision 1.11
diff -u -r1.11 xftcore.c
--- xftcore.c   16 Oct 2002 21:07:08 -0000      1.11
+++ xftcore.c   12 Feb 2003 19:07:56 -0000
@@ -1273,6 +1273,9 @@
        }
     }

+    if (x1 == x2 || y1 == y2)
+       goto bail1;
+
     for (i = 0; i < nglyphs; i++)
        if (((XftFontInt *) glyphs[i].font)->info.antialias)
            break;

Comment 7

[Christopher Blizzard (:blizzard)]

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

Comment 8

[keithp]

The fix for this bug is in XFree86 CVS and will be included in XFree86 4.3.

Comment 9

[Christopher Blizzard (:blizzard)]

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

Comment 10

[Christopher Blizzard (:blizzard)]

I get a lot of reports of this one.  I wonder if I can work around it in Moz.

Comment 11

[Christopher Blizzard (:blizzard)]

Attachment: patch

This patch is a work around.  Doing a gdk_flush after every string draw is
Ex-Pensive so I don't want to check this in as-is.  Maybe I can make a pref for
those that want the check or something if they are stuck with an old version of
Xft.

Comment 12

[Doug Turner (:dougt)]

this works for me.  

Comment 13

[keithp]

I'll bump the minor version of Xft so you can detect this through XftGetVersion
at runtime.

Comment 14

[keithp]

You only need the workaround if XftDefaultHasRender returns False, and you could
actually check the metrics of the string to see if it's empty and skip drawing
if it were.  A quick loop over all of the glyphs with an escape when you hit a
non-empty one would solve the problem with minimal performance impact.

Comment 15

[©tìpán Li¹ka]

I think, hardware and OS should be changed to more general ones if it is
connected with XFree impl. For me it crashes on PC/linux remoet XFree session,
for someone it could crash on PC/cygwin remote XFree session. Maybe, Summary
should be changed to.

Comment 16

[Christopher Blizzard (:blizzard)]

Keith, funny you should mention that since I just saw Xft version changes go
across another mailing list.  :)

Yeah, what you suggest is _exactly_ what I was planning.  I'll whip up another
patch.

Comment 17

[Christopher Blizzard (:blizzard)]

Attachment: patch

This emits a g_warning() if there's a problem with the version of Xft on the
system and works around it in that case.

Comment 18

[keithp]

The version check in the last patch is busted; the working version is 2.1.0:

   if (version < 20100)
        workaround = true;

Did you consider doing the metrics check instead of the error trap?  That would
eliminate almost all of the performance impact.

Comment 19

[Christopher Blizzard (:blizzard)]

Attachment: patch

Another approach that seems to work.  Also converts the Char calls to Glyph
calls, which I wanted to do anyway.

Comment 20

[Christopher Blizzard (:blizzard)]

Checked in.  Thanks for your help, guys.

Comment 21

[Christopher Blizzard (:blizzard)]

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