GNOME Bugzilla – Bug 113328
random gnome-panel crash WITH SOME SYMBOLS
Last modified: 2004-12-22 21:47:04 UTC
Package: gnome-panel Severity: critical Version: 2.2.0.1 Synopsis: random gnome-panel crash WITH SOME SYMBOLS Bugzilla-Product: gnome-panel Bugzilla-Component: Panel BugBuddy-GnomeVersion: 2.0 (2.2.0.1) Description: Description of Problem: gnome panel up and crashed on me. Fortunately, I installed the magic debugging RPM. I hope this is useful. Steps to reproduce the problem: 1. 2. 3. Actual Results: Expected Results: How often does this happen? Additional Information: Debugging Information: Backtrace was generated from '/usr/bin/gnome-panel' (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 1101)] 0x40923567 in waitpid () from /lib/i686/libpthread.so.0
+ Trace 37041
Thread 1 (Thread 16384 (LWP 1101))
------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-05-20 03:12 ------- The original reporter (lindahl@keyresearch.com) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org. Reassigning to the default owner of the component, gnome-panel-maint@bugzilla.gnome.org.
Looks like a unique trace, can anyone else reproduce?
Reporter, is there any way you can get a trace with full debugging symbols or find a set of steps that can be used to reproduce the crash. I don't think the backtrace provided is going to be of much use unfortunately.
The crash is random. Last time I submitted a report for it, I was told to install a special gnome debugging package, and I did. I've seen this crash 4 times in the last 2 and 1/2 years.
Awesome! Thanks for following up on this. They may not be useful (as Alex said), but these stack traces with debugging symbols are much more likely to be useful than the normal stack traces. It's sort of annoying because this bug is so rare and everyone who describes it says that they weren't even using gnome-panel when it crashed... Anyway, I've added a comment to bug 105745 (where these are sort of being tracked) asking if this is another duplicate and whether it's helpful or not. In the mean time, I'm setting version->2.2.x, and adding GNOMEVER2.2 & STACKTRACE & bugsquad keywords.
*** Bug 114546 has been marked as a duplicate of this bug. ***
Though the backtrace on first look looks quite useful, on further investigation it appears to be somewhat corrupt. Did gtk_window_get_toplevel() really get called with a NULL widget? Unlikely - the frame up looks like: if (widget) toplevel = gtk_widget_get_toplevel (widget); [And if it did get called with a NULL widget it would print out a warning and return harmlessly.] This backtrace looks to me like someone probably didn't unset the user data from a GdkWindow at unrealize time so it got left pointing at a non-existant window. And I do see multiple instances of that bug browing the gnome-panel sources; in: panel-util.c:stretch_widget_unrealize() And button-widget.c is missing an unrealize altogether. (The button->event_window will still get destroyed with the parent, but if you dont' call gdk_window_destroy() on it it will leak and get left with old user data pointing to the window.) (That's in gnome-2-2, in HEAD, I see only the button-widget.c problem, unless the panel-util.c stuff got moved elsewhere.) Certainly it's a leap of faith to think that the missing gdk_window_set_user_data() is causing these crashes, but fixing them would be a first step.
Owen: thanks much for looking into this. Yes, the stretching code is not longer on HEAD (thank goodness). I'm not sure I fully understand the issue with it, though. Are you saying that the window isn't being explicitly destroyed with gdk_window_destroy (I can't see where that's happening) or is it that we're leaving stale user_data references. If its the latter, I've committed a patch to gnome-2-2 which hopefully will fix that. I'll attach it. As for button->event_window not getting explicitly destroyed, I think the code is relying on the GtkButton unrealize() implementation which will correctly destroy the window. Not the smartest thing to do, but hardly the cause of this bug, right ?
Created attachment 17384 [details] [review] panel-util.c stetching code patch
Oh, I hadn't realized that the panel's button widget derives from GtkButton and then overrides the realize() code. That's pretty dubious practice, but yes, the unrealize should work correctly. Your patch for the stretch widget looks reasonable.
Thanks again. Okay, I think we'll close this out and re-visit it again if anyone manages to reproduce with either latest gnome-2-2 or 2.3.x.
Will you make a new gnome-panel for 2.2.2 then?
This looks similar to bug 109917 and bug 108205, both nautilus crashes. Interestingly, in bug 108205, it was found that the bug was due to "a patched version of GTK+ to add pretty (albeit buggy) drop shadow eyecandy and the like" and it was found that installing a clean version of gtk+ fixed the problem.
In this case I have a vanilla RedHat 9 install, with all RedHat updates. If you need me to, I can look through my logs and figure out exactly what version of gtk+ that I had installed.