Bug 5734 - crash with bitmap fonts containing 0x0 glyphs
Summary: crash with bitmap fonts containing 0x0 glyphs
Alias: None
Product: cairo
Classification: Unclassified
Component: freetype font backend (show other bugs)
Version: 1.1.1
Hardware: x86 (IA32) Linux (All)
: highest blocker
Assignee: Owen Taylor
QA Contact: cairo-bugs mailing list
: 4800 5433 5821 (view as bug list)
Depends on:
Reported: 2006-01-26 18:40 UTC by Behdad Esfahbod
Modified: 2006-04-12 21:44 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

patch 1 (1.87 KB, patch)
2006-01-26 18:41 UTC, Behdad Esfahbod
Details | Splinter Review
patch 2 (1.06 KB, patch)
2006-01-26 18:41 UTC, Behdad Esfahbod
Details | Splinter Review

Description Behdad Esfahbod 2006-01-26 18:40:14 UTC
[Originally posted here:

If a bitmap font has a 0x0 glyphs, the current
cairo-ft-font.c:_get_bitmap_surface returns a NULL surface:

-    if (width * height == 0) {
-       if (own_buffer && bitmap->buffer)
-           free (bitmap->buffer);
-       *surface = NULL;
-    } else {

which indeed crashes in the calling function immediately.  So I
first fixed that by fixing the calling function.  This is the
first patch attached.

But seems like (at least) the xlib backend expects non-NULL glyph

(gdb) f 0
#0  0x00477e66 in _cairo_xlib_surface_add_glyph (dpy=0x9ef1878,
    scaled_glyph=0xa1d4518) at cairo-xlib-surface.c:2121
2121        glyph_info.x = -(int) glyph_surface->base.device_x_offset;

So I backed up and removed the special case for 0x0 glyphs.
Everything seems to be fine now.  That's the second patch
attached.  I think it can be committed (with some format change
maybe), as 0x0 glyphs are not common enough to try to save a 0x0
surface for them...

Both patches fix another problem, _render_glyph_bitmap should
check the status returned by _get_bitmap_surface.
Comment 1 Behdad Esfahbod 2006-01-26 18:41:19 UTC
Created attachment 4477 [details] [review]
patch 1
Comment 2 Behdad Esfahbod 2006-01-26 18:41:42 UTC
Created attachment 4478 [details] [review]
patch 2
Comment 3 Behdad Esfahbod 2006-02-07 03:22:55 UTC
*** Bug 5433 has been marked as a duplicate of this bug. ***
Comment 4 Karderio 2006-02-07 04:30:16 UTC
This caused my gedit 2.13 to crash, the second patch fixed things fine.

Love, Karderio
Comment 5 Carl Worth 2006-02-21 05:53:04 UTC
The second patch (with appropriate formatting fixes) has been committed to
cairo's central (git-maintained) tree:

commit 57edf3f28fa09d2ec24d85dcc91a220d901a4452
Author: Carl Worth <cworth@raht.cworth.org>
Date:   Thu Feb 16 09:05:52 2006 -0800

    Normalize indentation after previous commit.

commit 0152bd3a562442853ab930eaea316c08b34f6ba6
Author: Carl Worth <cworth@raht.cworth.org>
Date:   Thu Feb 16 09:02:29 2006 -0800

    Allow _get_bitmap_surface to work for 0x0 glyphs, (fix for bug #5734).

    Patch from: Behdad Esfahbod <freedesktop@behdad.org>
    Reviewed by: Carl Worth <cworth@cworth.org>
Comment 6 Behdad Esfahbod 2006-02-24 07:43:49 UTC
*** Bug 5821 has been marked as a duplicate of this bug. ***
Comment 7 Behdad Esfahbod 2006-04-13 13:48:01 UTC
*** Bug 4800 has been marked as a duplicate of this bug. ***
Comment 8 Mitch 2006-04-13 14:34:34 UTC
So how exactly does the numbering convention work here ? From bug 4800 we're
told that the bug is fixed in version 1.0.4 of git, whereas i pull from cvs and
the last version was 1.1.1

% pkg-config --modversion cairo

So was there a reverse in versioning ? And why isn't cairo updates here



Comment 9 Behdad Esfahbod 2006-04-13 14:44:54 UTC
Humm, it's a bit overcomplicated.  1.0.4 is a bug-fix release in the 1.0 series,
while 1.1.1 is a CVS checkout of development between 1.0 and 1.2.  So yes, 1.0.4
was released after your 1.1.1 checkout was made.  That's how most of projects
with separate stable and development branches work these days.  The bug is also
fixed in the development tree, but that has been moved to git and the CVS is not
updated anymore.

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.