Red Hat Bugzilla – Bug 78036
Gnome-panel freezes (consistently) in Bluecurve
Last modified: 2008-05-01 11:38:04 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: I'm am experiencing a disturbing number of gnome-panel lockups under Bluecurve. The main panel (and any other panels I've created) simply quits responding to user input and locks up (no animations, including tool tips, mouse-over highlights, etc.). All applets stop responding as well, with the exception of the System Monitor applet, which continues to draw itself (but won't accept input). I can continue to use any windows I have open just fine. If I switch to a term and kill gnome-panel, the panels regenerate and all mouse-over animations work again, as well as the desktop switcher, until I click a launcher or menu, and then the whole panel(s) go back into the locked state. This occurs at least 4 times a day, and the only way to resolve it is to kill the gnome-session and restart. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1.Start Bluecurve/Gnome 2.Continue with normal use 3.Pull hair out when it happens, cause nothing will fix it save a gnome-session restart. Actual Results: Gnome-panel complete lockup. Expected Results: Gnome-panel should not lockup. Additional info:
Which applets are you using? Can you attach to gnome-panel with gdb while it's locked up, do: "gdb /usr/bin/gnome-panel <panel PID>" then type "backtrace" and paste the output here?
I'm using the following applets: system monitor, email checker (?), date/time, volume, rhn. Here's the backtrace: (gdb) backtrace #0 0x420cdb44 in read () from /lib/i686/libc.so.6 #1 0x4084ab44 in __JCR_LIST__ () from /lib/i686/libpthread.so.0 #2 0x408f0963 in esd_sample_play () from /usr/lib/libesd.so.0 #3 0x4027dd48 in gnome_triggers_do () from /usr/lib/libgnome-2.so.0 #4 0x4027de45 in gnome_triggers_vdo () from /usr/lib/libgnome-2.so.0 #5 0x4018f6cd in libgnomeui_module_info_get () from /usr/lib/libgnomeui-2.so.0 #6 0x4081aa07 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 #7 0x40819888 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #8 0x403d6fdf in gtk_signal_emit () from /usr/lib/libgtk-x11-2.0.so.0 #9 0x4047a5f5 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #10 0x403a3184 in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0 #11 0x403a231a in gtk_menu_shell_button_release () from /usr/lib/libgtk-x11-2.0.so.0 #12 0x403940e4 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #13 0x40806467 in g_type_class_meta_marshal () from /usr/lib/libgobject-2.0.so.0 #14 0x408060c0 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #15 0x4081a369 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 #16 0x40819689 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #17 0x403d6fdf in gtk_signal_emit () from /usr/lib/libgtk-x11-2.0.so.0 #18 0x4047a413 in gtk_widget_event_internal () from /usr/lib/libgtk-x11-2.0.so.0 #19 0x40393e67 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #20 0x40392b45 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #21 0x40543f21 in gdk_event_dispatch () from /usr/lib/libgdk-x11-2.0.so.0 #22 0x4088ef65 in g_main_dispatch () from /usr/lib/libglib-2.0.so.0 #23 0x4088ff98 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #24 0x408902ad in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #25 0x40890a1f in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #26 0x4039239f in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #27 0x0805aa01 in main () #28 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) Let me know if I can provide any further information. Thanks, John
It's apparently stuck trying to play a sound indicating you clicked a menu item. If you go to Preferences->Sound and turn all that stuff off, it may be a workaround. It may be worth checking ~/.xsession-errors for any messages about "esd" or "esound" or sound in general, checking permissions on /dev/dsp, and/or getting a backtrace from the sound daemon (esd) during the lock.
Moved to http://bugzilla.gnome.org/show_bug.cgi?id=103250