GNOME Bugzilla – Bug 99205
Panel crash
Last modified: 2004-12-22 21:47:04 UTC
Package: gnome-panel Severity: blocker Version: 2.0.6 Synopsis: Panel crash Bugzilla-Product: gnome-panel Bugzilla-Component: libpanel-applet BugBuddy-GnomeVersion: 2.0 (2.0.3) Description: Description of Problem: Panel crashed immidiately after the batt stat applet crashed Steps to reproduce the problem: 1. Boot 2. Make batt stat crash while booting 3. Actual Results: Panel crash Expected Results: No crash How often does this happen? Only happened once Additional Information: Debugging Information: Backtrace was generated from '/usr/bin/gnome-panel' (no debugging symbols found)...(no debugging symbols found)...[New Thread 8192 (LWP 1075)] 0x420ae169 in wait4 () from /lib/i686/libc.so.6
+ Trace 30742
Thread 1 (Thread 8192 (LWP 1075))
------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-11-21 11:15 ------- The original reporter (JuBColding@yorkref.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, mark@skynet.ie.
Can you reproduce this bug reliably ?
*** Bug 96197 has been marked as a duplicate of this bug. ***
Note that the reporter also filed bug 99206 and referenced this bug in that one. He also gave information in 99206 about how he got the batt stat applet to crash.
As to the first comment - No, I can not reproduce this. The batt stat applet crash is probably very depending on the timing of when I switch AC power on. I have tried to duplicate it with no luck.
I've experienced a crash with similar behavior--the battstat applet crashes (and bug-buddy is unable to get a stack trace) and the panel crashes immediately after it. Bug-buddy was able to get a stack trace of the panel crash and I filed it (as bug 99725). It has a fairly similar stack trace, but levels 6-7 here are different than levels 6-9 there. If the crash I got (bug 99725) is in fact the same as the one here, then I believe this bug is repeatable, but quite rare. I was trying to duplicate bug 94422 and repeatedly logged in, removed the redhat update icon, and logged out. Out of a couple hundred times of that, the battery applet crashed around 10-15 times or so (and did so immediately upon log in, before I even tried to remove the redhat update icon), and one or two of those times was followed by an immediate panel crash. Also, I think that the switching of the AC Power on as Jules reports was probably just coincidental. Of course, it's hard to tell with a fairly rare bug like this.
Mark/Arvind: there are some bugs like this one. E.g. bug #100404, bug #100197, bug #99725. An applet crashes when starting, and the last call from the applet is panel_applet_frame_*. Could it be only one bug ?
Vincent :bug #100404 and bug #99725 are dups of this but not sure on bug #100197. Mark, your fix to background stuff would fix 100197 ?
*** Bug 100404 has been marked as a duplicate of this bug. ***
*** Bug 99725 has been marked as a duplicate of this bug. ***
Okay, this should fix this: 2002-12-16 Mark McLoughlin <mark@skynet.ie> Be more robust in the face of applet crashes during loading. Should fix #99205. * panel-applet-frame.c: Keep a ref to the PanelWidget so that we can reload an applet even when it hasn't been fully loaded. (popup_handle_move), (panel_applet_frame_constrain_size), (panel_applet_frame_button_changed): use that ref here. (panel_applet_frame_reload_response): fix up to work even when an applet hasn't fully loaded. (panel_applet_frame_cnx_broken): don't require the applet to have been registered. (panel_applet_frame_construct): check for failure of vairious remote bonobo operations.