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

RESOLVED FIXED

Status

()

Core
Layout: Text
--
critical
RESOLVED FIXED
16 years ago
15 years ago

People

(Reporter: Tomas Ögren, Assigned: blizzard)

Tracking

({crash})

Trunk
Sun
Solaris
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

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

Updated

16 years ago
QA Contact: petersen → moied
->blizzard
Assignee: attinasi → blizzard
Blocks: 172768
Component: Layout → Layout: Fonts and Text
Keywords: crash

Comment 2

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

Comment 3

15 years ago
Critical severity.
Severity: normal → critical

Comment 4

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

Comment 5

15 years ago
Looks like an xft issue.

Comment 6

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

Comment 7

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

Updated

15 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Comment 8

15 years ago
The fix for this bug is in XFree86 CVS and will be included in XFree86 4.3.
(Assignee)

Comment 9

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

Comment 10

15 years ago
I get a lot of reports of this one.  I wonder if I can work around it in Moz.
(Assignee)

Comment 11

15 years ago
Created attachment 115456 [details] [diff] [review]
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

15 years ago
this works for me.  

Comment 13

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

Comment 14

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

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

(Assignee)

Comment 16

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

Comment 17

15 years ago
Created attachment 115502 [details] [diff] [review]
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.
Attachment #115456 - Attachment is obsolete: true

Comment 18

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

Comment 19

15 years ago
Created attachment 115534 [details] [diff] [review]
patch

Another approach that seems to work.  Also converts the Char calls to Glyph
calls, which I wanted to do anyway.
Attachment #115502 - Attachment is obsolete: true
(Assignee)

Comment 20

15 years ago
Checked in.  Thanks for your help, guys.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Assignee)

Comment 21

15 years ago
*** Bug 197415 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.