GNOME Bugzilla – Bug 567253
assertion from _cairo_status_is_error leads to crash
Last modified: 2009-02-12 11:47:50 UTC
Steps to reproduce: 1. make sure your using the clearlook engine in your GNOME theme 2. start epiphany 3. try to save an image on your hard drive Stack trace: (gdb) run Starting program: /usr/local/bin/epiphany [New process 15942, thread 0x878e0000] [New process 15942, thread 0x7ccdfc00] [New process 15942, thread 0x7f5bd000] [New process 15942, thread 0x7e4b3800] [New process 15942, thread 0x8a770400] [New process 15942, thread 0x85f4e000] [New process 15942] [New process 15942, thread 0x8171f800] assertion "_cairo_status_is_error (status)" failed: file "cairo.c", line 87, function "_cairo_error" Program received signal SIGABRT, Aborted. [Switching to process 15942, thread 0x7f252c00] 0x0738c5b5 in kill () from /usr/lib/libc.so.50.0 (gdb) bt
+ Trace 211441
Other information: I don't know if this can be reproduced in some other way, but with epiphany, it is 100% reproductable. It works just fine when using another gtk engine theme. This is under OpenBSD.
I can confirm this issue (on OpenBSD too). I have the following relevant modules installed: cairo: 1.8.4 gtk+2: 2.14.5 epiphany: 2.24.3 epiphany-extension: 2.24.3 glib2: 2.18.3 gtk2-engines: 2.16.1
Looks like something nasty is going on (though I don't think inside gtk-engines).
+ Trace 211526
1. The status values should not be that high 2. The status values should not differe AFAICT Are you running with progress bar animations enabled, or disable?
*** Bug 567727 has been marked as a duplicate of this bug. ***
The stack trace in bug 567727 probably has some more information.
OK, forget what I said about animation. This cannot be the problem, because it is a progress bar in a treeview. Maybe someone more knowledable of Epiphany/Mozilla could take a look? A wild guess what may be happening: 1. Epiphany shows the download window 2. Download window starts drawing 3. Download window/treeview/item is destroyed 4. Drawing code crashes If it was something like this, then the problem would be that epiphany is not doing proper locking in some place. I have no idea if this may be the cause ...
cc'ing epiphany-maint. Anyone have an idea about this?
So following comment (In reply to comment #5) > OK, forget what I said about animation. This cannot be the problem, because it > is a progress bar in a treeview. > > Maybe someone more knowledable of Epiphany/Mozilla could take a look? A wild > guess what may be happening: > 1. Epiphany shows the download window > 2. Download window starts drawing > 3. Download window/treeview/item is destroyed > 4. Drawing code crashes > > If it was something like this, then the problem would be that epiphany is not > doing proper locking in some place. I have no idea if this may be the cause ... > Epiphany crashes for me right after the "Downloads" dialog is created, just like you describe here.
> Epiphany crashes for me right after the "Downloads" dialog is created, just > like you describe here. The following patch for cairo, from NetBSD fixes the issue. --- src/cairo-clip.c.orig 2008-11-26 16:44:13.000000000 +0100 +++ src/cairo-clip.c @@ -423,7 +423,7 @@ _cairo_clip_intersect_mask (cairo_clip_t cairo_box_t extents; cairo_rectangle_int_t surface_rect, target_rect; cairo_surface_t *surface = NULL; - cairo_status_t status; + cairo_status_t status = CAIRO_STATUS_SUCCESS; if (clip->all_clipped) return CAIRO_STATUS_SUCCESS;
or rather, it's from upstream cairo in this commit; http://cgit.freedesktop.org/cairo/commit/?id=efa9e1088cbf1b5331cc0bab3348520f3b91ae4b
Well, then this issue is solved :-)
*** Bug 571337 has been marked as a duplicate of this bug. ***