As it's been reported here: http://foo-projects.org/pipermail/xfce/2006-March/016626.html there is definately something wrong (at least on my machine). Since the initial report I've recompiled gtk, xfce libs and xfdesktop with --enable-debug=yes, I've also upgraded gtk (on both 2.8.10 and 2.8.13 the results are the same) - unfortunately backtrace is even less informative. (See attachment). Reproducible: Always Steps to Reproduce: 1. on every startup, or when i try to start xfdesktop manually 2. 3. Actual Results: DBG[xfce-desktop.c:134] xfce_desktop_ensure_system_font_size(): dividing by PANGO_SCALE DBG[xfce-desktop.c:137] xfce_desktop_ensure_system_font_size(): system font size is 11.00000 DBG[xfdesktop-icon-view.c:1044] xfdesktop_setup_grids(): CELL_SIZE=107, TEXT_WIDTH=99, ICON_SIZE=32 DBG[xfdesktop-icon-view.c:1045] xfdesktop_setup_grids(): grid size is 8x11 DBG[xfdesktop-icon-view.c:1058] xfdesktop_setup_grids(): created grid_layout with 352 positions DBG[xfdesktop-icon-view.c:1059] xfdesktop_setup_grids 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 DBG[xfdesktop-icon-view.c:471] xfdesktop_icon_view_focus_in(): GOT FOCUS *** attempt to put segment in horiz list twice *** attempt to put segment in horiz list twice Bus error (core dumped) Expected Results: xfdesktop should not die :) Distro - Slackware 10.2, gtk+2-2.8.13, glib2-2.8.6, xfce packages compiled using svn snapshot (r20134).
Created attachment 465 Uninformative backtrace
Can you try running it through valgrind? Signal 7 is pretty rare, but usually indicates some kind of messed up memory access. Also ensure that you're using the absolutely most up-to-date version of xfdesktop.
(In reply to comment #2) > Can you try running it through valgrind? Signal 7 is pretty rare, but usually > indicates some kind of messed up memory access. Also ensure that you're using > the absolutely most up-to-date version of xfdesktop. Sure, if you need more specific valgrind output i'll need some hints. xfdesktop is from snapshots again (r20145), i've some troubles with autoconf if i try i compile directly from svn: configure.ac:29: error: possibly undefined macro: AC_PROG_INTLTOOL (probably because of different prefixes, i've intltool in /usr/local)
Created attachment 466 valgrind output
The only thing that looks odd to me is this: ==1985== Warning: client switching stacks? SP change: 0xBED682B4 --> 0x1 ==1985== to suppress, use: --max-stackframe=1093238093 or greater Not sure what that means, really. What kind of hardware are you on?
(In reply to comment #5) > The only thing that looks odd to me is this: > > ==1985== Warning: client switching stacks? SP change: 0xBED682B4 --> 0x1 > ==1985== to suppress, use: --max-stackframe=1093238093 or greater > > Not sure what that means, really. What kind of hardware are you on? An old Athlon XP 2200+.
Strange. Valgrind dies with a segfault, but xfdesktop alone dies with a bus error. Not sure if that's significant. Reassigning to xfce-bugs in case anyone else has any ideas...
(In reply to comment #7) > Strange. Valgrind dies with a segfault, but xfdesktop alone dies with a bus > error. Not sure if that's significant. Reassigning to xfce-bugs in case anyone > else has any ideas... When I compiled snapshot of 3rd of March (r20198+r20200) xfdesktop started to complain about some missing symbols and after a few minutes it led me to the /opt directory where i found the remains of libxfce4util. So, sorry for bothering you and taking your time. I really doubt that any of the recent svn changes solved the problem (/me ashamed), interesting is then fact that it was working for at least a month :> Regards, W.
Created attachment 474 Stack trace log Same here, It's rev. 20355 and this xfdesktop is linked against the ThunarVFS library (0.2.3svn-r20276), GTK+ 2.9.0, GLib 2.10.2.
Different bug, but same crash. Daichi, can you update to the latest rev and get a new backtrace? I just committed some modifications to the file where the crash is occurring. Looks like libgdk-pixbuf is barfing, but I suppose it's possible I'm corrupting memory somewhere.
I'd guess that the parameters to gdk_pixbuf_composite() are wrong. You are using the size passed to the icon_lookup() function to calculate the composite() parameters (IIRC composite() doesn't really validate its parameters), instead of determining the real width/height of the icon first. This is esp. likely as the symlink emblem icon returned for 48x48 will be around 24x24 in most icon themes (i.e. the GNOME icon theme).
Created attachment 475 Stack trace log Hi, it's rev. 20356 it still crashes. On a side note, it happened with Tango icon theme, now it's changed to Rodent, and when I install newly compiled gtk+, always `gtk-update-icon-cache -f' to refresh the caches.
Created attachment 476 Stack trace log It's rev. 20359, night.
Created attachment 477 Make log for Xfdesktop rev. 20379 FYI
Created attachment 478 Runtime log for Xfdesktop rev. 20379 FYI It comes with `--enable-debug=full'.
Hi, I found that it has nothing to with icon theme, just moving ~/Desktop to ~/Desktop.bak resolves the problem, that is, it was problematic desktop files that caused crash against xfdesktop: [dick@moose:~/Desktop.bak ]$ ls EQUINOX-3D (TM) 0.7.45 Welcome to SGI [dick@moose:~/Desktop.bak ]$ ls -l total 0 lrwx------ 1 dick user 25 Jul 13 2003 EQUINOX-3D (TM) 0.7.45 -> \ /usr/local/equinox/bin/eq lrwx------ 1 dick user 39 Feb 17 2004 Welcome to SGI -> \ /var/www/htdocs/WhatsNew/Welcome_to_SGI but I'm not sure which one (` ' or symbolic link) did cause a crash. anyway Wiktor, sorry for hijacking your bug account! I'll leave here.
Daichi, can you reproduce this with latest xfdesktop?
(In reply to comment #17) > Daichi, can you reproduce this with latest xfdesktop? Sure, however, I think that's not the point. Please close this bug account.
(In reply to comment #18) > (In reply to comment #17) > > Daichi, can you reproduce this with latest xfdesktop? > > Sure, however, I think that's not the point. > Please close this bug account. > Let's pretend that was a 'please close this bug' reply...