Assert failures in cairo-surface.c:1287: cairo_surface_set_device_offset: Assertion `status == CAIRO_STATUS_SUCCESS' failed, after upgrading to Oneiric with unity-2d

[Jacopo Lorenzetti]

After upgrading to Ubuntu 11.10, Chromium started crashing randomly with errors like:

[12848:12848:46799318261:ERROR:browser_main.cc(96)] Gtk: gtk_widget_size_allocate(): attempt to allocate widget with width -2147483648 and height 876
<snip>
chromium-browser: /build/buildd/cairo-1.10.2/src/cairo-surface.c:1287: cairo_surface_set_device_offset: asserzione "status == CAIRO_STATUS_SUCCESS" non riuscita.
Annullato

When the Gtk: gtk_widget_size_allocate() errors happen I can see the tabs width becoming very small and this is usually a few seconds before the crash. If I resize the browser's window the tabs return to the correct width and I get a few extra seconds before it crashes.

Visiting certain sites (like ebay) and opening new tabs seems to give more chances to crash, but not always.

Upgrading Chromium to 15.0.874.106 (Build 107270 Linux) from the proposed repository did not help. Nor it did disabling all the extensions.

I'm running a Ubuntu 2D session.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: chromium-browser 15.0.874.106~r107270-0ubuntu0.11.10.1
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic i686
ApportVersion: 1.23-0ubuntu4
Architecture: i386
CrashDB: ubuntu
Date: Wed Nov 9 02:05:00 2011
Desktop-Session:
 DESKTOP_SESSION = ubuntu-2d
 XDG_CONFIG_DIRS = /etc/xdg/xdg-ubuntu-2d:/etc/xdg
 XDG_DATA_DIRS = /usr/share/ubuntu-2d:/usr/share/gnome:/usr/local/share/:/usr/share/
Env:
 MOZ_PLUGIN_PATH = None
 LD_LIBRARY_PATH = None
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
ProcEnviron:
 PATH=(custom, user)
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
SourcePackage: chromium-browser
ThirdParty: True
UpgradeStatus: Upgraded to oneiric on 2011-11-04 (4 days ago)
chromium-default: CHROMIUM_FLAGS=""

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jacopo Lorenzetti (jacopol)]

Related to: http://developer.pidgin.im/ticket/13810

[Maarten Jacobs (maarten256)]

Folks - not sure if this problem is unique to Chromium.

I actually found the same issue with Banshee today. After some investigation of that problem I see there is a multitude of Cairo Assertion Failure bugs reported for Banshee as well - which all point to a mysterious "private" bug https://bugs.launchpad.net/bugs/830028.

I then did a wider search and saw a similar problem having been reported for GWibber - again a lot of bugs, all duplicates of each other, but eventually pointed to this bug.

Not quite sure what Cairo is, or what it does - I assume its part of some framework that various different applications rely on... I've not been able to find anything out there that seems to point to a fix for this - I know this problem has been around for a while now.

Anyways, just my two cents - if anybody has anything to add I'm happy to listen!

[Jacopo Lorenzetti (jacopol)]

I think the same.

If I understand, the same problem originates in Cairo/Pango (the 2D graphics library) and affects Gwibber, Pidgin, Chromium, Banshee and maybe others.

It would be nice to hear something from someone more expert.

[Jacopo Lorenzetti (jacopol)]

I tried installing libcairo2 1.10.2-2ubuntu2 from Natty (http://launchpadlibrarian.net/68707396/libcairo2_1.10.2-2ubuntu2_i386.deb) and libcairo2 1.10.2-6.1ubuntu2 from Precise (http://launchpadlibrarian.net/85598225/libcairo2_1.10.2-6.1ubuntu2_i386.deb) but the problem is always present.

[yaztromo (tromo)]

This probably the cause of a bug I reported to claws-mail developers as well. They think it is probably a cairo bug.

http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2656

claws-mail: /build/buildd/cairo-1.10.2/src/cairo-surface.c:1287:
cairo_surface_set_device_offset: Assertion `status == CAIRO_STATUS_SUCCESS'
failed.
Aborted (core dumped)

[yaztromo (tromo)]

Created attachment 61324
claws mail backtrace

Some users of Ubuntu 11.10 and 12.04 are getting program crashes along with this error.

claws-mail: /build/buildd/cairo-1.10.2/src/cairo-surface.c:1287:
cairo_surface_set_device_offset: Assertion `status == CAIRO_STATUS_SUCCESS'
failed.
Aborted (core dumped)

The above one is specific to claws mail but the error is basically the same for other software.

This is likely affecting Chromium browser, Pidgin, Banshee, Gwibber and Claws Mail.

Main thread for bug:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/887850

Others:
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2656
http://developer.pidgin.im/ticket/13810

[Chris Wilson (ickle)]

Already fixed and tell the applications to stop being buggy as well.

[yaztromo (tromo)]

Could you elaborate on that please?

Which bug number and version is this already fixed in?

What do you mean by "tell the applications to stop being buggy as well"? Surely if this is a cairo bug, then that has no relevance.

[Chris Wilson (ickle)]

No, the applications are not detecting errors (which result from their own bugs) correctly, consider this a friendly segfault.

[yaztromo (tromo)]

Lovely. So I'm left with nowhere to go now?

The developers of the other software blame cairo, and the developer of cairo blames the other software.

From my point of view so far this is a cairo or gtk bug. Since it affects multiple applications that use cairo. It would seem unlikely that they are all suddenly having the same bug on 11.10/12.04 at the same time.

Please could you be more forthcoming at least explain to me what this bug is about and tell me where this was fixed in cairo?

[yaztromo (tromo)]

Additionally here are the comments from Pidgin and claws

"doing a quick search for this cairo error message confirms my suspicions (or at
least make me more confident) that the bug is in cairo/pango"

and

"This isn't crashing in Pidgin, it's an upstream bug in Pango/Cairo, you should report this to your distro. "

[Kalle Vahlman (zuh)]

(In reply to comment #4)
> Lovely. So I'm left with nowhere to go now?
>
> The developers of the other software blame cairo, and the developer of cairo
> blames the other software.

That happens more than you'd think ;)

But in this case, the particular error message and the resulting abort is due to the application (or a library it's using) calling cairo_surface_set_device_offset() when the cairo context is already in an error state.

So unless it's a memory corruption or something similar in cairo, checking for the error state (or not causing it in the first place) is definitely something the application developers should look into.

[yaztromo (tromo)]

(In reply to comment #6)
> So unless it's a memory corruption or something similar in cairo, checking for
> the error state (or not causing it in the first place) is definitely something
> the application developers should look into.

Thank you Kalle for a much more helpful reply.

I could certainly go with what you said. My only sticking point is that this has suddenly affected a number of programs since 11.10. If it were only one then I could believe it is not a problem with cairo. But to have multiple software affected in the same way, when there was no problem at all in 11.04, would point the finger at cairo.

Also Chris alluded to the fact that he already knew about the problem with cairo when he said "already fixed", but in the next breath blamed other software. Something I ask him to elaborate on, which he seemed reluctant to do.

All I ask is that if it is "already fixed", could someone give me a bug number.

[Benjamin Otte (Company) (otte)]

What Chris meant to say was this:

This problem can only happen with broken applications.

Cairo 1.8 was written in a way to cope with these breakages. But somewhere along the way we lost that feature, because we don't test broken applications (and I don't think we intend to).

[Psychon-d (psychon-d)]

Can you get cairo 1.12.2 and check if this also happens with that cairo version?
I don't have any bug number for you, but there were lots of fixes since 1.10 and I can't easily tell how many of those affect cairo 1.10, too.

On your backtrace:
When this happens again, could you figure out the surface's state? In gdb, do "frame 5" and "print *surace"? However, this would need debug symbols for cairo which your earlier backtrace doesn't have (as can be seen by the invisible function arguments in the backtrace: "#5 0x00705f0a in cairo_surface_set_device_offset ()"). I think/hope there should be a package libcairo2-dbg for that.

I'm especially interested in surface->device_fransform.

[yaztromo (tromo)]

Thanks, I will get back to you as soon as I can.

[yaztromo (tromo)]

Reported to Cairo bugzilla at https://bugs.freedesktop.org/show_bug.cgi?id=49719

[Spitzak-k (spitzak-k)]

Isn't Cairo supposed to silently ignore all further commands when a cairo_t is in an error state?

It seems it is not, so I would say this is a Cairo bug, right?

[Psychon-d (psychon-d)]

Let me quote the (shortened) source:

void
cairo_surface_set_device_offset (cairo_surface_t *surface, double x_offset, double y_offset)
{
    cairo_status_t status;

    if (unlikely (surface->status))
 return;

[...]

    surface->device_transform.x0 = x_offset;
    surface->device_transform.y0 = y_offset;

    surface->device_transform_inverse = surface->device_transform;
    status = cairo_matrix_invert (&surface->device_transform_inverse);
    /* should always be invertible unless given pathological input */
    assert (status == CAIRO_STATUS_SUCCESS);

[...]
}

You can see different things:
- This function doesn't do anything on error surface (=> cairo correctly ignores operations on error surfaces)
- The only assert() in there has a comment which says "it's virtually impossible for this to fail"

I agree with this assert(). The device_transform should always be a translation matrix and those are always invertible. So unless I missed something, this leaves "random memory corruption" as the most likely case for this assert() to trigger (and debugging random memory corruption is hard and most likely not a bug in cairo).

Also, this is why I asked for someone to ask gdb which values the device_transform contains after a crash.

[Spitzak-k (spitzak-k)]

I think you are correct.

I thought it was doing the assert with surface->status. But it is doing it to the return value of a function which should not fail.

[Jacopo Lorenzetti (jacopol)]

yaztromo: Thank you.

[Bilal Shahid (s9iper1)]

i dont know why you have filed it in gwibber can you explain ?

[Jacopo Lorenzetti (jacopol)]

The assert failure in cairo-surface.c:1287: cairo_surface_set_device_offset has been reported in Gwibber (see duplicate bugs #811534, #830144, #843868, #859095, #863406).

The same problem has been found in multiple applications so I thought it could be a bug in libcairo, but Cairo's upstream says that it depends from the applications own bugs (https://bugs.freedesktop.org/show_bug.cgi?id=49719#c3, https://bugs.freedesktop.org/show_bug.cgi?id=49719#c6, https://bugs.freedesktop.org/show_bug.cgi?id=49719#c8), thus I'm filing it as affecting the single applications.

[Bilal Shahid (s9iper1)]

thanks for the info assigning to kenvandine

[Jacopo Lorenzetti (jacopol)]

Nice, thank you.

[Sergiocmailbox-freedesktop (sergiocmailbox-freedesktop)]

Hello.
webkitgtk browser (and browsers that use it like xxxterm - which changed name recently - and Midori) have been having this bug for quite a while (at least one year).
I personally experience it for a long time and I used Debian sid and currently I'm using Fedora 17 i686.

Here's the backtrace of /usr/libexec/webkitgtk/GtkLauncher when trying to open https://launchpad.net

http://pastebin.com/nvseMqbA

$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 6
model name : AMD Athlon(tm) XP 1700+
stepping : 2
cpu MHz : 1466.842
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up
bogomips : 2933.68
clflush size : 32
cache_alignment : 32
address sizes : 34 bits physical, 32 bits virtual
power management: ts

[Sergiocmailbox-freedesktop (sergiocmailbox-freedesktop)]

cairo package here is 1.10.2-7.fc17

[Sergiocmailbox-freedesktop (sergiocmailbox-freedesktop)]

Sorry, I see this is marked as invalid.
I tested the Fedora 18 live-cd with cairo 1.12.2-3.fc18 and webkitgtk's browser crashed with

GtkLauncher: cairo-surface.c:1591: cairo_surface_set_device_offset: Assertion `status == CAIRO_STATUS_SUCCESS' failed.

But now back in my F17 installed system I tried webkitgtk3 browser and this one works properly in https://launchpad.net [note it's the gtk3 browser instead of the gtk(2)]

I suspect I must bother someone in webkit.org about this then but I'm posting just in case anyone has any additional info on this.

Thanks.

[frenchy82 (cartes)]

I have too this problem with ubuntu 12.04 and ubuntu 12.10

chrome, chomium and midori crash on some websites (like french ubuntu forum where you can connect with a password)
status == CAIRO_STATUS_SUCCESS' failed

Epiphany works (maybe beause of the use of gtk3). I didn't try with midori-gtk3.

If you launch chrome with the parameter "google-chrome --password-store=basic" it works like a charm

Hope it could help

[frenchy82 (cartes)]

For me the only solution is to go back to libgcrypt11 1.4.3
With this, chrome, midori, chromium works nicely in ubuntu 12.04

[kardan (kardan+)]

(gdb) frame 5
#5 0x00705f6a in INT_cairo_surface_set_device_offset (surface=0x8d60e60, x_offset=-5, y_offset=-552)
    at /build/buildd/cairo-1.10.2/src/cairo-surface.c:1287
1287 /build/buildd/cairo-1.10.2/src/cairo-surface.c: Datei oder Verzeichnis nicht gefunden.

(gdb) print *surface
$1 = {backend = 0x781840, device = 0x85ac4c8, type = CAIRO_SURFACE_TYPE_XLIB, content = CAIRO_CONTENT_COLOR, ref_count = {
    ref_count = 1}, status = CAIRO_STATUS_SUCCESS, unique_id = 927, finished = 0, is_clear = 0, has_font_options = 0,
  owns_device = 1, user_data = {size = 0, num_elements = 0, element_size = 12, elements = 0x0, is_snapshot = 0},
  mime_data = {size = 0, num_elements = 0, element_size = 12, elements = 0x0, is_snapshot = 0}, device_transform = {
    xx = -nan(0x8000000000000), yx = -nan(0x8000000000000), xy = -nan(0x8000000000000), yy = -nan(0x8000000000000),
    x0 = -5, y0 = -552}, device_transform_inverse = {xx = -nan(0x8000000000000), yx = -nan(0x8000000000000),
    xy = -nan(0x8000000000000), yy = -nan(0x8000000000000), x0 = -5, y0 = -552}, device_transform_observers = {
    next = 0x8d60f08, prev = 0x8d60f08}, x_resolution = 72, y_resolution = 72, x_fallback_resolution = 300,
  y_fallback_resolution = 300, snapshot_of = 0x0, snapshot_detach = 0, snapshots = {next = 0x8d60f38, prev = 0x8d60f38},
  snapshot = {next = 0x8d631b0, prev = 0x8d63a30}, font_options = {antialias = CAIRO_ANTIALIAS_DEFAULT,
    subpixel_order = CAIRO_SUBPIXEL_ORDER_DEFAULT, lcd_filter = 148258000, hint_style = 4210701, hint_metrics = 148246160}}

[Dev-q (dev-q)]

unfortunately the problem still persists for 1.12.14
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2656#c17

[Psychon-d (psychon-d)]

Since everyone seems to be happy to provide more information:

Could you get debug symbols for gtk+ and figure out the local state in gdk_window_begin_paint_region()? So "frame 6" and "print *paint", "print *implicit_paint" and "print *paint->region", "print *implicit_paint->flushed", perhaps even "print *windows" and "print clip_box" (and for completeness: "print *paint->surface").

If you want to be really, really helpful, it would be great to have a stand-alone test case for this, but I doubt that this will show up.

[dino99 (9d9)]

Oneiric have reached EOL since a while and that issue is not reproducible with recent version(s)

[Daniel Manrique (roadmr)]

I'm not sure why this was marked as affecting ubuntu-friendly. Both oneiric and ubuntu-friendly are EOL so this bug is out of scope for either. I'll return this to affecting libcairo, as the upstream bug report refers to that. Thanks!

[dino99 (9d9)]

@rodmr

as per the upstream bug report comments, the latest libcairo having that issue was 1.12 and there is no activity since newer version is used. Chris Wilson mainly said that apps was faulty to not check some events coming from cairo/pango. The upgrades then seem to take care of such events; so no more report activity about that.
Sadly the freedesktop report remain open; and this cant be set 'invalid/fixed' directly inside launchpad. That's why an other package has been randomly chosen to then set it 'invalid'.