GNOME Bugzilla – Bug 327972
Crash when running 'killall gnome-panel'
Last modified: 2015-03-24 13:00:56 UTC
Got this after doing the above: (gdb) thread apply all bt
+ Trace 65449
Thread 1 (Thread -1208588624 (LWP 7529))
I can't reproduce this bug. the trash-applet died on me, though, when doing 'killall gnome-panel'.
I had to try a few times and every time a random applet seemed to crash... Maybe it's the libpanel-applet stuff that's to blame?
[Cc-ing Vincent Untz] by looking at the stack trace, I came up with a plausible explanation; feel free to hit me on the head if I seem totally on crack. the dictionary applet, like the trash applet, uses an idle function to queue the redraw of the widgets in case of background, orientation or size change. this I know, because I've stol... ehm... taken inspiration from the code in the trash applet. it seems that, when the panel receives the kill signal, it creates an event that triggers the idle function; the applet begins the idle loop, but it soon is destroyed - this triggers the segmentation fault (it tries to access the pixbuf used to hold the icon and it's empty). suggestion: maybe the panel should listen to the TERM and/or KILL signal, and destroy the various factories before actually quitting. I don't know how well it would play with the GTK's main loop, though. I repeat: I might be on crack, and gracefully handling a drastic action like a 'killall gnome-panel' could be overkill - no pun intended.
This happens in trashapplet, drivemount and possibly deskbar and gweather.
*** Bug 329935 has been marked as a duplicate of this bug. ***
For me, it crashes on restart, not when the panel is dying. Also, it will only crash for me on the top panel for some reason, putting the applet on the bottom panel doesn't seem to affect this. Also, if I have the cpu pegged (make -j2 running somewhere) then the applet seems to load up fine every time. If I have the cpu idle, it seems to crash, each and every time.
looks like a race condition happens somewhere between the panel and the factories. seems that the panel gets indeed killed, but the factories inside an idle loop do not get removed and their resources released, as if something is still holding a reference to them.
The codebases for at least two of these applets has changed minimally. I suspect we're looking for a change in libpanel-applet, the panel or Bonobo. I am marking this bug as release critical, because we've caused a pretty serious regression in here somewhere. I won't reassign this to libpanel-applet just yet.
(In reply to comment #7) > seems that the panel gets indeed killed, but the factories inside an idle loop > do not get removed and their resources released, as if something is still > holding a reference to them. I don't see why you believe this is related to shutdown. I did a 'gnome-session-remove gnome-panel' and the panel exited and no error was received. I even waited about 10 seconds to be sure. Then I ran 'gnome-panel &'. When I did, the panel came up, and bug-buddy popped up telling me that gnome-dictionary-applet had again crashed with the same stack trace.
Elijah, did the applet factories shut down when you shut the panel down? I've not had a lot of success in getting the applets to crash when I've had the factories in a debugger and killed the panel. The old factories shut down and new ones are started, which seems to support Emmanuele's race condition theory. This is strange, is this due to optimisation?
+ Trace 65917
(In reply to comment #10) > Elijah, did the applet factories shut down when you shut the panel down? Oh, I was assuming that they shut down automatically and that therefore a ten second wait would be enough to know that they had shut down. Shows how much I know. :) > This is strange, is this due to optimisation? I compile with the jhbuild defaults, which I assume are -g and -O2. *shrug*
(In reply to comment #11) > > Elijah, did the applet factories shut down when you shut the panel down? > > Oh, I was assuming that they shut down automatically and that therefore a ten > second wait would be enough to know that they had shut down. Shows how much I > know. :) They are meant to shut down automatically. When the last reference to the factory has been released, the factory should shut down. I am wondering if the factory has been put into some strange state due to it not shutting down cleanly.
Whee. I get much more exciting action on FC5t2. After removing panel from the session: [davyd@fc5t2 ~]$ gnome-panel ** ERROR **: file orbit-object.c: line 149 (do_unref): assertion failed: (robj->refs < ORBIT_REFCOUNT_MAX && robj->refs > 0) aborting... [davyd@fc5t2 ~]$ gdb `which gnome-panel` GNU gdb Red Hat Linux (6.3.0.0-1.94rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /usr/bin/gnome-panel Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xa4e000 [Thread debugging using libthread_db enabled] [New Thread -1208785232 (LWP 2764)] ** ERROR **: file orbit-object.c: line 149 (do_unref): assertion failed: (robj->refs < ORBIT_REFCOUNT_MAX && robj->refs > 0) aborting... Program received signal SIGTRAP, Trace/breakpoint trap.
+ Trace 65966
Thread NaN (LWP 2764)
Hmm, seems that I had an out of date libwnck on this machine and that was causing some strife. With the exception of Tomboy choosing the crash, I've gone back to not being able to replicate this.
Here is another strange backtrace, this one from mixer_applet2: *** glibc detected *** corrupted double-linked list: 0x00002aaaae9e5918 *** Program received signal SIGABRT, Aborted. (gdb) thread apply all bt
+ Trace 66084
Thread 1 (Thread 46912593612976 (LWP 27013))
Don't have full debugging symbols yet, but do we have any idea what is causing this?
See also: bug #327992
Can't reproduce. Is this still happening for someone here?
I can't reproduce this with any of the applets that are mentioned in this bugreport.
I can't reproduce either. Let's close it for now and reopen it if it starts happening again.
*** Bug 354135 has been marked as a duplicate of this bug. ***
*** Bug 344330 has been marked as a duplicate of this bug. ***
*** Bug 422635 has been marked as a duplicate of this bug. ***
*** Bug 491223 has been marked as a duplicate of this bug. ***