linux-traipu team mailing list archive

[Bug Watch Updater <887850@xxxxxxxxxxxxxxxxxx>]

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 UBUNTU -
AL - BR, which is subscribed to Chromium Browser.
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