Arch bug tracker is https://bugs.archlinux.org/task/29207

This fault does not occur on the one machine that I've now upgraded to gnome 3.4 / gtk 3.4

Seeing this on a Thinkpad X220 (x86_64, intel SNB)

From the Arch tracker, rebuilding with --disable-xlib-xcb also fixes the problem.

(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.

(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.

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.