Bug 48159 - gnome-settings-daemon crashes after upgrade to cairo 1.12
Summary: gnome-settings-daemon crashes after upgrade to cairo 1.12
Status: RESOLVED NOTOURBUG
Alias: None
Product: cairo
Classification: Unclassified
Component: xcb backend (show other bugs)
Version: 1.12.0
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Uli Schlachter
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-01 05:51 UTC by Jonathan Hudson
Modified: 2012-04-01 12:19 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
gdb stack trace across gsd, cairo, gtk3, glib2 (4.60 KB, text/plain)
2012-04-01 05:51 UTC, Jonathan Hudson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Hudson 2012-04-01 05:51:47 UTC
Created attachment 59337 [details]
gdb stack trace across gsd, cairo, gtk3, glib2

Since upgrading from cairo 1.10.2 (Arch package extra/cairo 1.10.2-3)
to 1.12 (Arch package testing/cairo 1.12.0-1), GNOME is unusable as
gnome-settings-daemon crashes within the cairo library.

Reverting to cairo 1.10.2 "fixes" the problem.

Attached is a stack trace. This is observed on 2 x86_64 machines (AMD CPUs,
AMD/ATI and NVidia cards with the free drivers). The problem is not
seen (i.e. 1.12 works as expected) on an ia-32 machine (Intel graphics).
Comment 1 Jonathan Hudson 2012-04-01 05:53:39 UTC
Arch bug tracker is https://bugs.archlinux.org/task/29207
Comment 2 Jonathan Hudson 2012-04-01 07:12:14 UTC
This fault does not occur on the one machine that I've now upgraded to gnome 3.4 / gtk 3.4
Comment 3 Jan Alexander Steffens (heftig) 2012-04-01 07:13:22 UTC
Seeing this on a Thinkpad X220 (x86_64, intel SNB)
Comment 4 Jonathan Hudson 2012-04-01 07:46:23 UTC
From the Arch tracker, rebuilding with --disable-xlib-xcb also fixes the problem.
Comment 5 Uli Schlachter 2012-04-01 10:01:25 UTC
(In reply to comment #4)
> From the Arch tracker, rebuilding with --disable-xlib-xcb also fixes the
> problem.

Sure, any bug in xlib-xcb can be worked around that way.

I cannot reproduce the crash here with gnome-settings-daemon 3.2.2-3 from debian testing (but without a full gnome session).

Could you do 'print *(cairo_xlib_xcb_surface_t*)surface' and 'print *(((cairo_xlib_xcb_surface_t*)surface)->xcb)' in gdb? This smells a lot like some memory corruption or a wild pointer being passed to cairo.
Comment 6 Jonathan Hudson 2012-04-01 10:42:21 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > From the Arch tracker, rebuilding with --disable-xlib-xcb also fixes the
> > problem.
> 
> Sure, any bug in xlib-xcb can be worked around that way.
> 
> I cannot reproduce the crash here with gnome-settings-daemon 3.2.2-3 from
> debian testing (but without a full gnome session).

I cannot reproduce it on two of the 'N' computers here either.

> Could you do 'print *(cairo_xlib_xcb_surface_t*)surface' and 'print
> *(((cairo_xlib_xcb_surface_t*)surface)->xcb)' in gdb? This smells a lot like
> some memory corruption or a wild pointer being passed to cairo.

Here's the results (with the print commands prefixed with ##). This is in a raw X session, with just metacity / gnome-terminal, in which I run:

$ gdb /usr/lib/gnome-settings-daemon/gnome-settings-daemon


694	    if (surface->xcb->base.type != CAIRO_SURFACE_TYPE_XCB) {

## print *(cairo_xlib_xcb_surface_t*)surface
$1 = {base = {backend = 0x7ffff574f5a0, device = 0x0, 
    type = CAIRO_SURFACE_TYPE_XLIB, content = CAIRO_CONTENT_COLOR, 
    ref_count = {ref_count = 5}, status = CAIRO_STATUS_SUCCESS, 
    unique_id = 128, serial = 1, damage = 0x0, finished = 0, is_clear = 0, 
    has_font_options = 0, owns_device = 0, user_data = {size = 0, 
      num_elements = 0, element_size = 24, elements = 0x0}, mime_data = {
      size = 0, num_elements = 0, element_size = 24, elements = 0x0}, 
    device_transform = {xx = 1, yx = 0, xy = 0, yy = 1, x0 = 0, y0 = 0}, 
    device_transform_inverse = {xx = 1, yx = 0, xy = 0, yy = 1, x0 = -0, 
      y0 = -0}, device_transform_observers = {next = 0x845740, 
      prev = 0x8455a8}, x_resolution = 72, y_resolution = 72, 
    x_fallback_resolution = 300, y_fallback_resolution = 300, 
    snapshot_of = 0x0, snapshot_detach = 0x18010000002b, snapshots = {
      next = 0x909108, prev = 0x909108}, snapshot = {next = 0x2c00000000, 
      prev = 0xf000800000f01}, font_options = {antialias = 983044, 
      subpixel_order = 983040, lcd_filter = CAIRO_LCD_FILTER_DEFAULT, 
      hint_style = CAIRO_HINT_STYLE_DEFAULT, hint_metrics = 45, 
      round_glyph_positions = 3841}}, xcb = 0x0, display = 0xc8000000c8, 
  screen = 0x909290, visual = 0x0, format = 0x170}
## print *(((cairo_xlib_xcb_surface_t*)surface)->xcb)
Cannot access memory at address 0x0

Even with my 'I'm just a simple user' hat on, the latter does not look good.
Comment 7 Uli Schlachter 2012-04-01 12:19:26 UTC
The font_options in that surface are definitely corrupt (antialias = 983044, subpixel_order = 983040, hint_metrics = 45, round_glyph_positions = 3841). If these number are converted to hex, you get antialias = 0xf0004, subpixel_order = 0xf0000. That looks a bit similar to the 0xf008.... in snapshot.prev. A pattern? The snapshot_detach pointer looks fishy, too, but that might just be unitialized memory (why doesn't _cairo_surface_init() set this to NULL?)

So I guess something evil corrupted everything past the snapshot.next pointer. As a next step to investigate this, I would propose to run this under valgrind, but I will just claim that this is not a bug in cairo and close this. Sorry.


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.