After resuming to use my laptop after it has been suspended, the panel is gone from my session. The only clue is this message in .xsession-errors: (xfce4-panel:4541): Gtk-WARNING **: A floating object was finalized. This means that someone called g_object_unref() on an object that had only a floating reference; the initial floating reference is not owned by anyone and must be removed with gtk_object_sink() after a normal reference is obtained with g_object_ref(). ** Message: xfce4-panel: Exit Items on the panel are: netload, wavelan plugin, cpu graph, system buttons, system load, xfce-clock, graphical pager, battery monitor, and a few launchers.
I don't think Xfce should have to care about suspend/resume, should it? Sounds like an operating system task to me.
I'm not sure how a suspend/resume could cause that error, but without a backtrace, it's obviously going to be hard to diagnose. I wouldn't rule out a bona fide bug in the panel or a plugin, though...
Some more info: The panel isn't segfaulting. It is in fact receiving a TERM signal. Where this signal is originating from I don't know. I rebuilt the package (this is the os-cillation package) to not strip debugging symbols. Running it under gdb provided no new information. If anyone could provide me with some help on how to drive gdb to get useful info I would be happy to try it out. The error message mentioned in comment #0 also appeared when I manually removed the wavelan plugin. The panel however didn't exit. Removing the plugin didn't help with the panel exiting issue. This makes me wonder if there might not be two seperate issues.
Resuming my laptop after suspend to RAM causes the same problem like in comment #0. I run the xfc4 debian-packages from os-cillation, the OS is Debian/sarge. I do not use the session manager. The problem even occurs if I remove almost all plugins/starters from panel (except one terminal starter). It seems that the problem is really specific to xfce4-panel, suspend/resume works fine with other window managers like IceWM on my machine. ----------------------------------------------------------------- /bin/sh /usr/X11R6/bin/startx xinit /home/peter/.xinitrc -- /usr/X11R6/lib/X11/xinit/xserverrc /usr/bin/X11/X -dpi 100 -nolisten tcp /usr/bin/xfce4-panel /usr/bin/xfce-mcs-manager /usr/bin/xfwm4 --daemon /usr/bin/xfdesktop -----------------------------------------------------------------
Maybe someone can explain to me what resume from suspend is supposed to do? It looks to me like the panel receives a signal and exits. What kind of signal could that be?
Suspending usually halts alsa, which causes the panel to exit. This might be the same as bug 935. Try stopping also and see if that causes the panel to exit on your machine.
It certainly looks possible that alsa is the culprit. I haven't been able to verify it (I have alsa compiled into the kernel rather than as modules), but the init.d script certainly goes through and kills of any processes that are using alsa. I'm surprised though that the panel uses alsa. I can't recall it emitting any sounds, and I removed the volume control applet when I started looking at the issue. Anyway, once I get a bit of time I'll recompile it to use alsa modules instead, and see what happens.
Finally got round to recompiling the kernel with alsa as modules rather than built in, and the panel has survived a sleep/resume cycle. Of course it might also be that I upgraded from kernel 2.6.7 to 2.6.13, but I suspect this will not have made any difference.
Thanks for testing this. I don't think there is anything Xfce can do, so I'm resolving this as INVALID. Updating alsa and/or the kernel seems the best solution.
One final comment is that at least on debian /etc/default/alsa had to be edited to make the "force_unload_modules_before_suspend" variable is blank.