User-Agent: Mozilla/5.0 (X11; U; Linux i686; it; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8 Build Identifier: it happens only when xfdesktop is set to handle icons using Thunar. Whenever I switch from AC or to AC xfdesktop exits and Thunar crashes. xfdesktop seems not buggy, because without icon handling it wont crash. Reproducible: Always Steps to Reproduce: 1. switch to or from AC Actual Results: xfdesktop along with thunar exits Expected Results: no crash gentoo base system, thunar-svn just update, thunar-0.8.0 gave me the same result
Paste the log messages here.
Created attachment 1450 xfdesktop strace when crashing I've just re-upgraded from svn, and now when xfdesktop is set to handle the desktop icons, when unplugging, it exists, while Thunar will not. I truly have no idea what's happening here. Do I need an exorcist? the output log is from "strace -p XXX -o log". tell me if you need something else or with different switches.
Attach the messages printed on stdout.
Weird, never seen or heard of this before. Definitely doesn't happen on my laptop. Yes, console output would be useful...
Created attachment 1453 xfdesktop-2.log strace (attached to pid) Tomorrow I did some other tests on it: today infact I get: $ ps ax | grep -iE "(thunar|xfdesktop)" 8083 ? S 0:01 /usr/bin/xfdesktop --sm-client-id 117f000001000118410039300000083760006 --display :0.0 8087 ? S 0:00 /usr/bin/Thunar --daemon Before unplugging I did: $ strace -p 8087 -o thunar-2.log Process 8087 attached - interrupt to quit Process 8087 detached and $ strace -p 8083 -o xfdesktop-2.log Process 8083 attached - interrupt to quit Process 8083 detached as you can see: both thunar and xfdesktop crashed :-\ next will come the thunar-2.log
Created attachment 1454 thunar-2.log strace (attached to pid) thunar log on crash (see previous post)
Created attachment 1455 xfdesktop-2.1.log strace (from the start) After both thunar and xfdesktop have crashed I stared xfdesktop thruogh strace (log attached: xfdesktop-2.1.log) and it gave me NO console OUTPUT: $ strace -o xfdesktop-2.1.log xfdesktop $ (thunar chrashed too, but didn't monitor) I should at this point clarify something on my machine: I'm handling power management via init scripts: $ diff -d /etc/runlevels/battery/ /etc/runlevels/default/ Only in /etc/runlevels/default/: cpufrequtils Only in /etc/runlevels/battery/: ncpufreqd so I use two different daemons depending if I'm under AC or battery. Apart from this I'm using ivman+hald+dbus to handle automounting of devices: I don't know if this matters, but since we are dealing with volume icons I have to include it for completeness.
Can people please stop posting straces when you've just been asked to post console output? strace isn't useful here.
(In reply to comment #8) > Can people please stop posting straces when you've just been asked to post > console output? strace isn't useful here. > I'm sorry. anyway there's no output. (In reply to comment #7) > After both thunar and xfdesktop have crashed I stared xfdesktop thruogh strace > (log attached: xfdesktop-2.1.log) and it gave me NO console OUTPUT: > > $ strace -o xfdesktop-2.1.log xfdesktop > $ > > (thunar chrashed too, but didn't monitor) I even recompiled thunar (svn) and xfdesktop (still 4.4.1-r1) with --debug and xfdesktop doesen't report anything about the crash. Instead it seems to be a random crash caused by someone else. I don't know how to catch debug messages of Thunar: starting it via "thunar --daemon" or attaching strace to the running process started by xfdesktop are of no help as Mr. Tarricone stated. The only thing that can put in relation the "battery" and the "desktop" is the battery-plugin. but anyway something (IMHO) should be reported by anyone of those two progs crashing... still no clue.
It may not be crashing - run it through gdb and see.
I run xfdestkop from gdb and it gave me: > [Thread -1269507184 (LWP 31990) exited] > [Thread -1282950256 (LWP 31989) exited] > [Thread -1238406256 (LWP 31987) exited] > > Program exited with code 01. > (gdb) same did thunar > [New Thread -1236138272 (LWP 32016)] > [New Thread -1251054704 (LWP 32019)] > [New Thread -1259447408 (LWP 32020)] > [New Thread -1267840112 (LWP 32021)] > [New Thread -1276232816 (LWP 32022)] > [New Thread -1284625520 (LWP 32023)] > [New Thread -1293431920 (LWP 32024)] > [Thread -1293431920 (LWP 32024) exited] > [Thread -1267840112 (LWP 32021) exited] > [Thread -1251054704 (LWP 32019) exited] > [Thread -1259447408 (LWP 32020) exited] > [Thread -1284625520 (LWP 32023) exited] > [Thread -1276232816 (LWP 32022) exited] > > > Program exited with code 01. > (gdb)
Just guessing, but does the dbus daemon terminates?
That was going to be my next question as well. Also -- if the dbus daemon is still running, check to see if hald is still running too (though I've never seen either of those quit in response to just hal going away).
No, hald is not important. But the shared DBusConnection used by Thunar/xfdesktop terminates the application if the connection to the D-Bus daemon is lost. My guess is that your runlevel switch restarts the dbus system daemon, which explains why the applications using the shared connections are terminated with an exit code of 1.
ok, I monitored dbus. Normally I get three dbus running on my system: # ps aux | grep dbus peach 9437 0.0 0.0 2712 668 ? S 10:11 0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session peach 9438 0.0 0.0 2228 916 ? Ss 10:11 0:00 /usr/bin/dbus-daemon --fork --print-pid 4 --print-address 7 --session 101 32563 0.0 0.0 2220 848 ? Ss 11:04 0:00 /usr/bin/dbus-daemon --system 101 is the user set up by dbus. Upon unplugging the AC cable the third process is restarting so I tried with strace (sorry but I didn't manage to debug it via gdb) and it gave me this: > gettimeofday({1196849992, 222542}, NULL) = 0 > gettimeofday({1196849992, 222607}, NULL) = 0 > poll([{fd=6, events=POLLIN}, {fd=9, events=POLLIN}], 2, -1) = -1 EINTR (Interrupted system call) > --- SIGTERM (Terminated) @ 0 (0) --- > sigreturn() = ? (mask now []) > gettimeofday({1196849997, 975310}, NULL) = 0 > close(6) = 0 > unlink("/var/run/dbus/system_bus_socket") = -1 EACCES (Permission denied) > unlink("/var/run/dbus.pid") = -1 EACCES (Permission denied) > exit_group(0) = ? I don't know what is making dbus to be killed, this is quite strange.
It's possible that some power management daemon, or some plug/unplug event scripts, are causing system services to restart, which is what would cause that to happen. What distro are you using? You should probably try one of their mailing lists or forums to track down exactly what's going on. Benny, is it possible to gracefully handle a dbus disconnection and try to reconnet? I recall looking into this a while ago without really getting anywhere. Really, this sounds like a pretty bad bug in either dbus or dbus-glib that it's always a fatal error if the dbus daemon goes away.
As said, the switch in runlevel restarts dbus-daemon (assuming that you are using Gentoo). The disconnect-on-exit is the default for the shared DBusConnections returned by libdbus. It's a sane solution for the low-level stuff. The problem is that libdbus-glib is quite bogus in that it doesn't provide a high-level abstraction, but basically only the marshalling/unmarshalling to GObject value types. I'm working on a real high-level GObject binding for libdbus together with high-level GObject bindings for HAL for nearly 2 years now, which adds some smartness. It's already working in most ways, but it's not yet finished (lack of time, as usual). I'm trying to finish the IDL compiler right now; I'll import the stuff into SVN once it's working.
(In reply to comment #16) > It's possible that some power management daemon, or some plug/unplug event > scripts, are causing system services to restart, which is what would cause that > to happen. What distro are you using? You should probably try one of their > mailing lists or forums to track down exactly what's going on. sure, as stated I'm using Gentoo. I'll try to see if someone is reporting similar errors on gentoo bugzilla or the forums. I'll report in later to see if there's a workaround this dbus issue related to the soft runlevel switch. the daemon, IMHO, should not be restarted since it's in both the default and battery runlevels. thanks anyway for pointing me to the right direction.