tux paint launcher in gnome-panel causes gnome panel to be unusable (reproduable fixable)

Thanks for your bug report. I tried it on my box too, but I wasn't able to
reproduce it. Which version of Ubuntu do you use?

i cant reproduce it here either

i just tried it on my sudoer account and it dosnt happen, only on the
none sudoer account i set up for my wife to use.

(In reply to comment #2)
> i cant reproduce it here either

I can, though, on Hoary 5.04 with updates and tuxpaint. I was about to rm -rf
~/.gnome and crash my gconf had not a bit of gconf investigation been done ;)

Can someone attach the desktop file that causes problem to this bug?

I also had these postings for bug #21064
which involved adding an application to gnome-panel.

---------------------------------------------------
I was able to reliably get a similar crash with Ubuntu 5.10
I have the package edubuntu installed (if this makes any difference)
This is on an AMD Sempron 2200 machine.

To get the gnome-panel to crash:

1. Create a new user acount
2. Login to this new acount (from the Ubuntu gdm display manager)
3. Add an application to the gnome-panel (I added tuxpaint)

   Applications > Graphics > Tux_Paint (right-click, Add this to launcher panel)

4. Then immediately resize the launcher panel

   Right-click the launcher panel > Properties > then repeatedly click the
little up arrow to make the panel bigger

   On about the 2nd, 3rd click the panel crashes. The panel starts blinking and
then disappears.
   Even if you re-login the problem remains. You have no panel showing.

   If you do a [crtl][alt][backspace] to leave this now crippled session
   the gdm login screen does NOT return. There is "gdm" process running somewhere.
   To get the login screen back you have to kill the running gdm and restart it.

   The crash seems to scramble a setting somewhere in the .gnome2 directory.
   If you completely erase ~/.gnome2 and let the system rebuild it for you
   then the account is useable again.
---------------------------------------------------

Also....

I was also able to crash gnome-panel if I

1. Resized the launcher panel bigger
2. then immediately added an application to the launcher panel
   (this also happened to be TuxPaint).

I can reproduce this here (up-to-date breezy, not upgraded from hoary -- breezy
installer). This was on a non-sudoer account as well (newly created), though I
didn't try it with another account.

I got the bug by logging into the new account, adding tuxpaint to the top panel
(right-click on tuxpaint from the menu), then opening the panel properties and
increasing its size by clicking on the top arrow (crash after two or three clicks).

Created an attachment (id=5363)
Desktop file for tuxpaint

Here is the /usr/share/gnome/apps/Graphics/tuxpaint.desktop file.

See also bug #21064

It looks like the launcher entry for tuxpaint gets truncated with some
information missing at the end.

The corrupt entry should be in a file named something like this:

~/.gnome2/panel2.d/default/launcher/gegl-**********.desktop

If I remove this file then gnome-panel works again at next login.

Manu (or someone else): can you attach the desktop file that is in
~/.gnome2/panel2.d/default/launcher/ :-) (the one that's truncated)

Thanks

Created an attachment (id=5375)
User-local desktop file

See the file above. I also launched a newly-compiled gnome-panel with gdb, and
had the same bug (segfault). Here's the backtrace :

(gdb) run
Starting program: /home/essai/gnome-panel-2.12.1/gnome-panel/gnome-panel
[Thread debugging using libthread_db enabled]
[New Thread -1223477568 (LWP 5285)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223477568 (LWP 5285)]
0xb7ddb43a in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
(gdb) bt
#0 0xb7ddb43a in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#1 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#2 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#3 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#4 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#5 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#6 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#7 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#8 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#9 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#10 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#11 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#12 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#13 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#14 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#15 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#16 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#17 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#18 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#19 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#20 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#21 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#22 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#23 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#24 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#25 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#26 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#27 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#28 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#29 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#30 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#31 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#32 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#33 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#34 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
---Type <return> to continue, or q <return> to quit---
#35 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#36 0xb7ddb4c0 in art_bezier_to_vec () from /usr/lib/libart_lgpl_2.so.2
#37 0xb7...

OK I was wrong.

I set up two machines with only 1 gnome-panel entry i.e. tuxpaint.

I compared
a (known broken) Ubuntu 5.10 tuxpaint gnome-panel launcher
with a (known working) Debian sarge tuxpaint gnome-panel launcher.

Each of the two files in ~/.gnome2/panel2.d/default/launcher/ are __identical__.

Ubutu doesn't like tuxpaint? :^)

This is a libart/librsvg issue:

0xb7dbf66c in art_vpath_render_bez (p_vpath=0xbfe63a18, pn=0xbfe63a14,
pn_max=0xbfe63a10, x0=Cannot access memory at address 0xbf667f78
) at art_vpath_bpath.c:125
125 {
(gdb) bt
#0 0xb7dbf66c in art_vpath_render_bez (p_vpath=0xbfe63a18, pn=0xbfe63a14,
pn_max=0xbfe63a10, x0=Cannot access memory at address 0xbf667f78
) at art_vpath_bpath.c:125
#1 0xb7dbfa5e in art_vpath_render_bez (p_vpath=0xbfe63a18, pn=0xbfe63a14,
pn_max=0xbfe63a10, x0=383739974313028.19,
    y0=13.717218822740477, x1=383739974313028.25, y1=13.717218822740477,
x2=383739974313028.25, y2=13.717218822740477,
    x3=383739974313028.25, y3=13.717218822740477, flatness=0.25) at
art_vpath_bpath.c:228

...

Breakpoint 1, art_vpath_render_bez (p_vpath=0xbfd8b9e8, pn=0xbfd8b9e4,
pn_max=0xbfd8b9e0, x0=26.779200856494665,
    y0=23.252268861967494, x1=26.779200856494665, y1=25.571342815257175,
x2=20.576632879860302, y2=27.451323704601091,
    x3=12.925377529524667, y3=27.451323704601091, flatness=0.25) at
art_vpath_bpath.c:161
161 x3_0 = x3 - x0;
(gdb) bt
#0 art_vpath_render_bez (p_vpath=0xbfd8b9e8, pn=0xbfd8b9e4, pn_max=0xbfd8b9e0,
x0=26.779200856494665,
    y0=23.252268861967494, x1=26.779200856494665, y1=25.571342815257175,
x2=20.576632879860302, y2=27.451323704601091,
    x3=12.925377529524667, y3=27.451323704601091, flatness=0.25) at
art_vpath_bpath.c:161
#1 0xb7de7dc6 in art_bez_path_to_vec (bez=0x82ca830, flatness=0.25) at
art_vpath_bpath.c:303
#2 0xb691eaf0 in rsvg_art_render_path () from /usr/lib/librsvg-2.so.2
#3 0xb691c8bc in rsvg_render_path () from /usr/lib/librsvg-2.so.2
#4 0xb6911854 in rsvg_clip_path_parse () from /usr/lib/librsvg-2.so.2
#5 0xb6914885 in rsvg_node_draw () from /usr/lib/librsvg-2.so.2
#6 0xb6914911 in _rsvg_node_draw_children () from /usr/lib/librsvg-2.so.2
#7 0xb6914885 in rsvg_node_draw () from /usr/lib/librsvg-2.so.2
#8 0xb6914e92 in rsvg_node_group_pack () from /usr/lib/librsvg-2.so.2
#9 0xb6914885 in rsvg_node_draw () from /usr/lib/librsvg-2.so.2
#10 0xb691cb16 in rsvg_handle_get_pixbuf () from /usr/lib/librsvg-2.so.2
#11 0xb693cbf2 in ?? () from /usr/lib/gtk-2.0/2.4.0/loaders/svg_loader.so
#12 0x08283df8 in ?? ()
#13 0xbfd8cd98 in ?? ()
#14 0x000006c4 in ?? ()
#15 0x00000000 in ?? ()

It works fine using librsvg 2.13.3 which uses cairo, so it'll be fixed at the
next librsvg update to dapper

Fixed with this upload:

 librsvg (2.13.4-0ubuntu1) dapper; urgency=low
 .
   * Sync with Debian
   * New upstream version
   * debian/control.in:
     - build with firefox instead of mozilla
     - Build-Depends on libcairo2-dev and not on libart
   * debian/librsvg2-dev.install:
     - new tarball doesn't ship the documentation, updated for that
   * debian/patches/paint-server.patch:
     - not required with the new upstream version
   * debian/rules:
     - updated the shlibs version