After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 113328 - random gnome-panel crash WITH SOME SYMBOLS
random gnome-panel crash WITH SOME SYMBOLS
Status: RESOLVED FIXED
Product: gnome-panel
Classification: Other
Component: panel
2.2.x
Other other
: Normal critical
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 114546 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-05-20 07:12 UTC by lindahl
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
panel-util.c stetching code patch (1.65 KB, patch)
2003-06-10 12:10 UTC, Mark McLoughlin
none Details | Review

Description lindahl 2003-05-20 07:12:34 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

Thread 1 (Thread 16384 (LWP 1101))

  • #0 waitpid
    from /lib/i686/libpthread.so.0
  • #1 libgnomeui_module_info_get
    from /usr/lib/libgnomeui-2.so.0
  • #2 __pthread_sighandler
    from /lib/i686/libpthread.so.0
  • #3 <signal handler called>
  • #4 gtk_widget_get_toplevel
    at gtkwidget.c line 5356
  • #5 gtk_main_get_window_group
    at gtkmain.c line 1569
  • #6 gtk_main_do_event
    at gtkmain.c line 1394
  • #7 gdk_event_dispatch
    at gdkevents-x11.c line 2018
  • #8 g_get_current_time
    from /usr/lib/libglib-2.0.so.0
  • #9 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #10 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #11 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #12 gtk_main
    at gtkmain.c line 1092
  • #13 main
  • #14 __libc_start_main
    from /lib/i686/libc.so.6
  • #0 waitpid
    from /lib/i686/libpthread.so.0




------- 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.

Comment 1 Alex Duggan 2003-05-20 12:24:26 UTC
Looks like a unique trace, can anyone else reproduce?
Comment 2 Alex Duggan 2003-05-20 12:26:17 UTC
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.
Comment 3 Greg Lindahl 2003-05-20 16:32:19 UTC
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.
Comment 4 Elijah Newren 2003-06-10 04:31:54 UTC
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.
Comment 5 Owen Taylor 2003-06-10 10:51:12 UTC
*** Bug 114546 has been marked as a duplicate of this bug. ***
Comment 6 Owen Taylor 2003-06-10 11:07:36 UTC
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.
Comment 7 Mark McLoughlin 2003-06-10 12:09:53 UTC
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 ?
Comment 8 Mark McLoughlin 2003-06-10 12:10:48 UTC
Created attachment 17384 [details] [review]
panel-util.c stetching code patch
Comment 9 Owen Taylor 2003-06-10 12:25:13 UTC
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.

Comment 10 Mark McLoughlin 2003-06-10 12:34:44 UTC
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.
Comment 11 Kjartan Maraas 2003-06-10 19:13:05 UTC
Will you make a new gnome-panel for 2.2.2 then?
Comment 12 Elijah Newren 2003-07-08 16:01:06 UTC
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.
Comment 13 Greg Lindahl 2003-07-08 17:49:28 UTC
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.