Bug 4705

Summary: crash at XRenderAddGlyphs
Product: cairo Reporter: Jinghua Luo <sunmoon1997>
Component: xlib backendAssignee: Carl Worth <cworth>
Status: RESOLVED FIXED QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: critical    
Priority: high CC: sangu.xorg
Version: 1.1.1   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: cairo-debug.log
a patch to fix this bug.
a updated one.
updated patch
Support multiple glyph image formats within the same font.

Description Jinghua Luo 2005-10-07 07:01:46 UTC
while running some apps against cairo-1.1.0, app crashed and i got 
something like follow.
fcitx: BadLength (poly request too large or internal Xlib length error)
X Error of failed request:  BadLength (poly request too large or
internal Xlib length error)
  Major opcode of failed request:  150 (RENDER)
  Minor opcode of failed request:  20 (RenderAddGlyphs)
  Serial number of failed request:  721
  Current serial number in output stream:  722.
the problem is:
currenty cairo xlib backend assume that the depth of glyphs from a font
face are the same, but this is not true for some embedded bitmap fonts.
The may have two different depth glyphs, from my attached file, you can
see the fist eight glyphs are 1-bit depth bitmap, but latter ones' depth
become 8-bit. Cairo only extracts the format information from the fisrt
glyph, if glyph's depth changed, cairo'll still use the old formation info,
and send the glyph to X server, then X will complain cairo sended too much
bits to it and reply an error (bad length) that will crash a lot of apps.

This only happens with cairo-1.1.1, cairo-1.0.x works fine.
Comment 1 Jinghua Luo 2005-10-07 07:03:50 UTC
Created attachment 3506 [details]
cairo-debug.log
Comment 2 Jinghua Luo 2005-10-07 07:07:58 UTC
Created attachment 3507 [details] [review]
a patch to fix this bug.

This is my patch to fix this bug.
Comment 3 Jinghua Luo 2006-02-28 13:23:35 UTC
Created attachment 4772 [details] [review]
a updated one.
Comment 4 Jinghua Luo 2006-02-28 13:44:45 UTC
I found the real bug is in cairo-ft-font.c, it creates different format glyphs
in a font and xlib backend can't handle that. I have a fix in my local tree but
I'm currently in busy and have no time to clean the patch and submit it here. I
updated the patch for xlib backend, this patch workarounds the problem in
cairo-ft-font.c(I think it's also a feature for xlib backend, supports different
format glyghs in a font) and cairo won't crash any more. what's you guys idea?
Apply this patch, leap the real bug and let it to be fixed in cairo-1.4?
Comment 5 Jinghua Luo 2006-04-26 18:01:26 UTC
Created attachment 5479 [details] [review]
updated patch
Comment 6 sangu 2006-04-26 23:00:30 UTC
Visiting http://gitweb.freedesktop.org/?p=cairo;a=log , firefox 1.5.0.2  (using
pango text) crashes in cairo 1.1.2.

But after patching attachment 5479 [details] [review] , firefox works well.

OS : Fedora development (20060426)
Comment 7 Dan Williams 2006-04-29 00:02:30 UTC
Ran into this issue with evolution now, 2006-04-26 patch fixes the problem for me.

Backtrace looked like:

#4  0x00bb630a in XSync () from /usr/lib/libX11.so.6
#5  0x00bb6485 in XSetAfterFunction () from /usr/lib/libX11.so.6
#6  0x00f12a79 in XRenderAddGlyphs () from /usr/lib/libXrender.so.1
#7  0x00234392 in _cairo_xlib_surface_old_show_glyphs (scaled_font=0x917a8a0,
op=CAIRO_OPERATOR_OVER, pattern=0xbfb16490, abstract_surface=0x91843a0,
source_x=19, source_y=342, dest_x=19,
     dest_y=342, width=41, height=11, glyphs=0x918ed20, num_glyphs=3) at
cairo-xlib-surface.c:2191
Comment 8 Carl Worth 2006-05-02 05:00:57 UTC
Created attachment 5542 [details] [review]
Support multiple glyph image formats within the same font.

Keith and I took a look at this bug and the previously proposed patch.

We don't think the previous patch is the right approach to the problem. I'm
attaching the beginnings of an alternate approach. The new 4705-convert.patch
should eliminate the crashes. Can someone please test this? (make sure the
other patch is not already applied first).

Or if someone could provide a font, (or the name of an available font), that
has these multi-format glyph images in it, that would help me to replicate the
problem.

If the new patch solves the crash then I will commit it to cairo. It's not
quite as functional as the previous patch as it will make all glyphs from a
font be rendered with the same format (A1 or A8, say), but will choose which
format simply by which glyph it sees first.

An improvement over this scheme would be to choose A1 or A8 depending on
whether an A8 glyph images are present in the font, (and if so, then the patch
I've provided would then convert any A1 glyph images to A8). I don't actually
know how to detect this right now, (and again, having access to a font with
both formats inside would be necessary).

Thanks,

-Carl
Comment 9 Dan Williams 2006-05-02 07:25:02 UTC
Carl's 4705-convert.patch _also_ does fix the issue for me.  (Need to change
_CAIRO_FORMAT_TO_XRENDER_FORMAT -> _CAIRO_FORMAT_XRENDER_FORMAT though)
Comment 10 Carl Worth 2006-05-02 07:57:57 UTC
With that confirmation, I've now pushed the new patch out to cairo's master
branch, (in 1.1.3), and I'm closing this bug on the crash.

If someone wants to open a new bug saying that fonts with A8 glyph images
sometimes render them as A1, then that would be fine, (particularly if there's a
patch for _cairo_xlib_surface_font_init along with it).

-Carl
Comment 11 sangu 2006-05-12 15:02:14 UTC
Please See : http://bugzilla.gnome.org/show_bug.cgi?id=341138
Connecting http://gitweb.freedesktop.org/?p=cairo;a=log in Pango 1.13.0 + cairo  
1.1.16, firefox (using PangoText) begines to eating big memory. and firefox uses
All memory. 

Related this bug 4705 ?
Comment 12 Zhangrong Huang 2006-06-10 01:36:50 UTC
cairo should support multiple glyph image formats within the same font, I met
the problem, I filed a new bug, pls see
https://bugs.freedesktop.org/show_bug.cgi?id=7172

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.