step to reproduce: $ ln -s /usr/share/applications/$APP.desktop ~/Desktop/$APP.desktop Xfdesktop crash
I cannot reproduce this. I did: ln -s /usr/share/applications/gaim.desktop ~/Desktop/gaim.desktop The new icon appeared on the desktop, no problem. Can you provide a backtrace? What version and svn revision of xfdesktop are you using?
I remember a thunar bug that Benny fixed that had to do with a crash with desktop file parsing. Maybe the particular desktop file you used was triggering the bug? Anyway, unless you can provide a backtrace, I'm just going to mark this WORKSFORME.
it crashes when there's a symlink on the desktop and icon size is chosen to be < 25. In that case compositing the symlink emblem over the icon crashes in gtk_pixbuf_composite(), possibly because dest size is 8 pixels? gtk2.10 but I think it happened with 2.8 as well Here's an ubuntu bug I could reproduce today. https://launchpad.net/distros/ubuntu/+source/xfdesktop4/+bug/46623 happens with todays' svn
No, I've worked on this a bit, and there's something else going on here. When I call gdk_pixbuf_composite() all the values passed are correct (via a printf), however, if I step through the code in gdb, at the point right before I hit the crash, somehow one of the parameters (i think it was dest_x in my case) ended up somehow changing its value. Usually that would indicate some kind of memory corruption, but I can't seem to find it. Unfortunately I'm stuck... not sure what to do.
Benny - hate to drag you into this, but you're our resident expert on obscure stuff. Any ideas why this could be occurring? Side note, the icon size doesn't seem to matter. I can reproduce it with 48px icons. The icon *theme* does seem to matter though. Rodent crashes when I symlink in /usr/share/applications/gnome-system-monitor.desktop, whereas Tango crashes when I symlink in an xfmedia screenshot I have in another directory. The crashes don't occur for those respective files if I swap icon themes. Stack corruption? Not sure how. I was afraid maybe there was some weirdness in the MMX-optimised pixops routines in gtk, but I see the crash on my ppc box as well.
Created attachment 732 Suggested fix The problem is actually pretty simple: The dst pixbuf you pass to gdk_pixbuf_composite() may reside in the icon cache, which is mapped read-only, and so it cannot write to that pixbuf. You should in general not modify any pixbufs returned from the icon theme. The patch fixes the problem.
Huh, I had no idea that was the case. Well that's a PITA. Guess you learn something new every day. Like the fact that you should actually *read* the API documentation. This type of thing might fix some other bugs I'm struggling with now as well, so I'll look into this tonight hopefully. Thanks, Benny. Really appreciate it.
Ok, should be fixed.