gnome-panel crashes in _cairo_pen_find_active_cw_vertex_index() when opening menu

[Mark Fenton]

Binary package hint: gnome-panel

After upgrading from edgy to feisty the gnome panel crashes whenever the Accessories menu is accessed. I have tracked this down to being caused by the gnome-screenshot.desktop launcher (Attatched. This file also crashes nautilus and the menu editor). Can someone else confirm this with the attatched file?

[Mark Fenton (mark-fenton)]

Here is a tar of the file since it also crashes the gnome browser if I try and upload the original

[Sebastien Bacher (seb128)]

Thanks for your bug report. Please try to obtain a backtrace http://wiki.ubuntu.com/DebuggingProgramCrash and attach the file to the bug report. This will greatly help us in tracking down your problem.

[Mark Fenton (mark-fenton)]

Thanks for your help. Here is the backtrace.

[Sebastien Bacher (seb128)]

Could you get an another backtrace with librsvg2-2-dbgsym installed and use "thread apply all bt full" rather than "bt" on the gdb prompt?

[Mark Fenton (mark-fenton)]

No problem, see attatched.

[Sebastien Bacher (seb128)]

The bug has been opened on https://launchpad.net/bugs/88605

"Binary package hint: gnome-panel

After upgrading from edgy to feisty the gnome panel crashes whenever the Accessories menu is accessed. I have tracked this down to being caused by the gnome-screenshot.desktop launcher (Attatched. This file also crashes nautilus and the menu editor). Can someone else confirm this with the attatched file?
...
http://librarian.launchpad.net/6568011/gnome-panel-bt.txt
gnome-panel backtrace "thread apply all bt full"

0xb7fd9410 in __kernel_vsyscall ()
(gdb) continue
Continuing.

Program received signal SIGABRT, Aborted.
[Switching to Thread -1225623872 (LWP 20270)]
0xb7fd9410 in __kernel_vsyscall ()
(gdb) thread apply all bt full

Thread 1 (Thread -1225623872 (LWP 20270)):
#0 0xb7fd9410 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb74fedf0 in raise () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#2 0xb7500641 in abort () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#3 0xb74f843b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#4 0xb78de7af in _cairo_pen_find_active_cw_vertex_index (pen=0xbfd7a7c4,
    slope=0xbfd7a6e0, active=0xbfd7a6e8)
    at /build/buildd/libcairo-1.3.14/src/cairo-pen.c:323
        i = 4
        __PRETTY_FUNCTION__ = "_cairo_pen_find_active_cw_vertex_index"
#5 0xb78dcef4 in _cairo_stroker_add_cap (stroker=0xbfd7a7ac, f=0xbfd7a710)
    at /build/buildd/libcairo-1.3.14/src/cairo-path-stroke.c:380
        i = <value optimized out>
        stop = <value optimized out>
        slope = {dx = 186413, dy = -41235}
        tri = {{x = 1281686, y = 421457}, {x = -186413, y = 41235}, {
    x = -422821683, y = -1074839899}}
        pen = (cairo_pen_t *) 0xbfd7a7c4
---Type <return> to continue, or q <return> to quit---
        start = <value optimized out>
        status = <value optimized out>
#6 0xb78dd165 in _cairo_stroker_add_leading_cap (stroker=0x0,
    face=<value optimized out>)
    at /build/buildd/libcairo-1.3.14/src/cairo-path-stroke.c:451
        reversed = {ccw = {x = 1281686, y = 421457}, point = {x = 1281686,
    y = 421457}, cw = {x = 1281686, y = 421457}, dev_vector = {dx = 186413,
    dy = -41235}, usr_vector = {x = 0.97639746740062494,
    y = -0.21598144747557721}}
#7 0xb78dd195 in _cairo_stroker_add_caps (stroker=0xbfd7a7ac)
    at /build/buildd/libcairo-1.3.14/src/cairo-path-stroke.c:483
        status = <value optimized out>
#8 0xb78dd59c in _cairo_path_fixed_stroke_to_traps (path=0x83fee30,
    stroke_style=0x8434830, ctm=0x84348cc, ctm_inverse=0x84348fc,
    tolerance=0.10000000000000001, traps=0xbfd7a8d0)
    at /build/buildd/libcairo-1.3.14/src/cairo-path-stroke.c:999
        status = CAIRO_STATUS_SUCCESS
        stroker = {style = 0x8434830, ctm = 0x84348cc,
  ctm_inverse = 0x84348fc, tolerance = 0.10000000000000001,
  traps = 0xbfd7a8d0, pen = {radius = 0, tolerance = 0.10000000000000001,
    vertices = 0x8413dc0, num_vertices = 4}, current_point = {x = 1095273,
    y = 462692}, first_point = {x = 1281686, y = 421457}, has_sub_path = 1,
  has_current_face = 1, current_face = {ccw = {x = 1095273, y = 462692},
---T...

[Sebastien Bacher (seb128)]

What theme do you use? Does it happen if you change it? I've forwarded the bug upstream: https://bugs.freedesktop.org/show_bug.cgi?id=10231

[Freedesktop (freedesktop)]

Can you reproduce and print *pen in _cairo_pen_find_active_cw_vertex_index?

[Freedesktop (freedesktop)]

Also can you attach the SVG that causes the crash? The .desktop file is not useful.

[Freedesktop (freedesktop)]

Other than *pen, "pen->vertices[0]@8" is interesting too.

[Sebastien Bacher (seb128)]

Comments from upstream:

"Can you reproduce and print *pen in _cairo_pen_find_active_cw_vertex_index?"

"Also can you attach the SVG that causes the crash? The .desktop file is not
useful."

"Other than *pen, "pen->vertices[0]@8" is interesting too."

[Mark Fenton (mark-fenton)]

The icon theme is "eXperience", changing it back to the standard GNOME theme does make the error go away. I've attatched the SVG file which I think the shortcut is using (which seems to cause the same error with Nautilus as the .desktop file). I'm afraid I'm not quite sure how to get the other information they want - I'll have a go if they can explain a bit further. Hope this all helps, and thanks again.

[Sebastien Bacher (seb128)]

ubuntu duplicate example: http://librarian.launchpad.net/6823930/cracher-from-openwengo.svg

[Carl Worth (cworth)]

(In reply to comment #4)
> ubuntu duplicate example:
> http://librarian.launchpad.net/6823930/cracher-from-openwengo.svg

Excellent, thank you!

With this svg image I can replicate the bug, (with simply "rsvg-view cracher-from-openwengo.svg"), so a fix should not be far away now.

-Carl

[Carl Worth (cworth)]

(In reply to comment #5)
> With this svg image I can replicate the bug, (with simply "rsvg-view
> cracher-from-openwengo.svg"), so a fix should not be far away now.

OK. It's easy enough to spot the bug. It's triggered by the stroke-width="0", (which appears _many_ times in that file).

That's an embarrassing little bug in cairo, but will be simple enough to fix.

Meanwhile, I wonder what that SVG file is doing with all the stroke-width="0" elements in it. According to the SVG specification, a "zero value causes no stroke to be painted" [http://www.w3.org/TR/SVG/painting.html#StrokeProperties].

But anyway, I'll be back with a patch quite soon.

-Carl

[Carl Worth (cworth)]

Clarifying that the bug only occurs with CAIRO_LINE_CAP_ROUND.

[Carl Worth (cworth)]

Created an attachment (id=9173)
Minimal SVG test case to demonstrate bug

Here's the minimal SVG test case I've been able to write to demonstrate the bug.

Oddly enough, when I've written the trivial transliteration of this SVG file to a C test case, it's not triggering the bug. Still looking...

-Carl

[Freedesktop (freedesktop)]

(In reply to comment #8)
> Created an attachment (id=9173) [details]
> Minimal SVG test case to demonstrate bug
>
> Here's the minimal SVG test case I've been able to write to demonstrate the
> bug.
>
> Oddly enough, when I've written the trivial transliteration of this SVG file to
> a C test case, it's not triggering the bug. Still looking...

Yeah, cause my first guess was that, I tried stroke-width of zero and all epsilons greater than zero. It worked. Either got 4 different points in the pen, or the pen code was not called at all.

> -Carl

[Freedesktop (freedesktop)]

Ok, the examples hits a case where the four points of the pen are all 0,0. I tried to get that case with no luck. Investigating.

[Freedesktop (freedesktop)]

Ok, how silly I am. It happens with stroke_extents(), not stroke()... That's why I failed to reproduce it...

[Carl Worth (cworth)]

Yeah, we both made the same mistake trying to reproduce this one.

Anyway, all fixed now, (and tested in cairo's test suite now as well):

http://gitweb.freedesktop.org/?p=cairo;a=commitdiff;h=133183d858aa632da3cec2a789dcc1e1203d778b

Thanks very much for the report.

We're shooting for a cairo 1.4.2 release in early April that will include this fix.

-Carl

[Sebastien Bacher (seb128)]

fixed upstream

[Sebastien Bacher (seb128)]

This upload fixes the bug:

 libcairo (1.4.2-0ubuntu1) feisty; urgency=low
 .
   * New upstream version:
     - fix "evolution crashed with SIGSEGV during print" (Ubuntu: #83744)
     - fix "gnome-panel crashes in _cairo_pen_find_active_cw_vertex_index()
       when opening menu" (Ubuntu: #88605)
   * debian/patches/01_fix_directfb_build.dpatch:
     - dropped, fixed with the new version

[Benjamin Otte (Company) (otte)]

*** Bug 13293 has been marked as a duplicate of this bug. ***

[Riccardo-datahost (riccardo-datahost)]

I'm getting this with swfdec from git and cairo 1.4.10 from debian, reported in swfdec as 13293.

Program received signal SIGABRT, Aborted.
---Type <return> to continue, or q <return> to quit---
[Switching to Thread 0xb718e920 (LWP 9961)]
0xb736f7d6 in raise () from /lib/libc.so.6
(gdb) bt full
#0 0xb736f7d6 in raise () from /lib/libc.so.6
No symbol table info available.
#1 0xb73710f1 in abort () from /lib/libc.so.6
No symbol table info available.
#2 0xb7368b50 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#3 0xb77b7f4f in _cairo_pen_find_active_cw_vertex_index (pen=0xbfd43f00,
    slope=0xbfd43dd0, active=0xbfd43dd8)
    at /home/rm/swfdec/cairo/libcairo-1.4.10/src/cairo-pen.c:324
        i = 4
        __PRETTY_FUNCTION__ = "_cairo_pen_find_active_cw_vertex_index"
#4 0xb77b668e in _cairo_stroker_add_cap (stroker=0xbfd43ee8, f=0xbfd43e00)
    at /home/rm/swfdec/cairo/libcairo-1.4.10/src/cairo-path-stroke.c:397
        i = <value optimized out>
        stop = <value optimized out>
        slope = {dx = -2, dy = -1}
        tri = {{x = 39324, y = 62256}, {x = 0, y = 1}, {x = 0, y = 0}}
        pen = (cairo_pen_t *) 0xbfd43f00
        start = <value optimized out>
        status = <value optimized out>
#5 0xb77b6945 in _cairo_stroker_add_leading_cap (stroker=0x0,
    face=<value optimized out>)
    at /home/rm/swfdec/cairo/libcairo-1.4.10/src/cairo-path-stroke.c:480
---Type <return> to continue, or q <return> to quit---
        reversed = {ccw = {x = 39324, y = 62256}, point = {x = 39324,
    y = 62256}, cw = {x = 39324, y = 62256}, dev_vector = {dx = -2, dy = -1},
  usr_vector = {x = -0.89442719099991586, y = -0.44721359549995793}}
#6 0xb77b6976 in _cairo_stroker_add_caps (stroker=0xbfd43ee8)
    at /home/rm/swfdec/cairo/libcairo-1.4.10/src/cairo-path-stroke.c:520
        status = <value optimized out>
#7 0xb77b6d1c in _cairo_path_fixed_stroke_to_traps (path=0xa83abe8,
    stroke_style=0xa83b378, ctm=0xbfd443a8, ctm_inverse=0xbfd44378,
    tolerance=0.10000000000000001, traps=0xbfd44024)
    at /home/rm/swfdec/cairo/libcairo-1.4.10/src/cairo-path-stroke.c:1024
        status = CAIRO_STATUS_SUCCESS
        stroker = {style = 0xa83b378, ctm = 0xbfd443a8,
  ctm_inverse = 0xbfd44378, tolerance = 0.10000000000000001,
  traps = 0xbfd44024, pen = {radius = 10, tolerance = 0.10000000000000001,
    vertices = 0xa28b990, num_vertices = 4}, current_point = {x = 39324,
    y = 62256}, first_point = {x = 39324, y = 62256},
  has_initial_sub_path = 0, has_current_face = 1, current_face = {ccw = {
      x = 39324, y = 62256}, point = {x = 39324, y = 62256}, cw = {x = 39324,
      y = 62256}, dev_vector = {dx = 0, dy = 1}, usr_vector = {x = 0, y = 1}},
  has_first_face = 1, first_face = {ccw = {x = 39324, y = 62256}, point = {
      x = 39324, y = 62256}, cw = {x = 39324, y = 62256}, dev_vector = {
      dx = 2, dy = 1}, usr_vector = {x = 0.89442719099991586,
      y = 0.44721359549995793}}, dashed = 0, dash_index = 3218358248,
---Type <return> to continue, or q <return> to quit---
  dash_on = -1216433589, dash_starts_on = -1216441344, dash_remain = 0}
#8 0xb77c01c5 in _cairo_surface_fallback_stroke (surface=0x...

[Carl Worth (cworth)]

The above report of a duplicate (13293) and re-opnening of this bug is not useful.

*This* original bug was carefully disagnosed to be as described, (a crash when the line width is 0.0 and the line cap is round). It was first fixed in the 1.4.2 release and remains fixed, (as verified by the line-width-zero test in the test suite).

Benjamin and Riccardo, obviously you've found another bug, (that exists in 1.4.10). Let's please use a separate report for that. (And when you open it, please provide as minimal a test case as possible so that we can identify the conditions of the bug).

I'm marking this as fixed again, so I don't have to go re-read all of the history, and re-run the test just to discover that it's still working fine.

-Carl

[Riccardo-datahost (riccardo-datahost)]

*** Bug 14338 has been marked as a duplicate of this bug. ***