Launchpad has imported 17 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=49719.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2012-05-10T01:25:48+00:00 yaztromo wrote: 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 Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/16 ------------------------------------------------------------------------ On 2012-05-10T01:36:46+00:00 Chris Wilson wrote: Already fixed and tell the applications to stop being buggy as well. Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/17 ------------------------------------------------------------------------ On 2012-05-10T02:51:18+00:00 yaztromo wrote: 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. Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/18 ------------------------------------------------------------------------ On 2012-05-10T03:17:23+00:00 Chris Wilson wrote: No, the applications are not detecting errors (which result from their own bugs) correctly, consider this a friendly segfault. Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/19 ------------------------------------------------------------------------ On 2012-05-10T03:23:50+00:00 yaztromo wrote: 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? Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/20 ------------------------------------------------------------------------ On 2012-05-10T03:45:53+00:00 yaztromo wrote: 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. " Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/21 ------------------------------------------------------------------------ On 2012-05-10T06:03:14+00:00 Kalle Vahlman wrote: (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. Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/22 ------------------------------------------------------------------------ On 2012-05-10T07:17:02+00:00 yaztromo wrote: (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. Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/23 ------------------------------------------------------------------------ On 2012-05-10T07:49:54+00:00 Benjamin Otte (Company) wrote: 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). Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/24 ------------------------------------------------------------------------ On 2012-05-10T08:00:13+00:00 Psychon-d wrote: 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. Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/25 ------------------------------------------------------------------------ On 2012-05-10T08:07:20+00:00 yaztromo wrote: Thanks, I will get back to you as soon as I can. Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/26 ------------------------------------------------------------------------ On 2012-05-10T11:50:01+00:00 Spitzak-k wrote: 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? Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/28 ------------------------------------------------------------------------ On 2012-05-10T11:55:34+00:00 Psychon-d wrote: 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. Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/29 ------------------------------------------------------------------------ On 2012-05-10T12:23:40+00:00 Spitzak-k wrote: 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. Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/30 ------------------------------------------------------------------------ On 2012-09-18T19:49:42+00:00 Sergiocmailbox-freedesktop wrote: 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 Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/36 ------------------------------------------------------------------------ On 2012-09-18T19:51:48+00:00 Sergiocmailbox-freedesktop wrote: cairo package here is 1.10.2-7.fc17 Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/37 ------------------------------------------------------------------------ On 2012-09-18T21:47:33+00:00 Sergiocmailbox-freedesktop wrote: 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. Reply at: https://bugs.launchpad.net/banshee/+bug/887850/comments/38 ** Changed in: libcairo Status: Unknown => Invalid ** Changed in: libcairo Importance: Unknown => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/887850 Title: 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 Status in Banshee Music Player: New Status in Chromium Browser: New Status in a fast and powerful GTK+ based mail client: New Status in FileZilla FTP Client: New Status in Gwibber: Triaged Status in libcairo - cairo vector graphics library: Invalid Status in Pidgin: New Status in “chromium-browser” package in Ubuntu: Confirmed Bug description: 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="" To manage notifications about this bug go to: https://bugs.launchpad.net/banshee/+bug/887850/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
