GNOME Bugzilla – Bug 328057
wnck-applet crashes on dual head display
Last modified: 2006-01-26 10:11:04 UTC
Distribution: Slackware Slackware 10.2.0 Package: gnome-panel Severity: Normal Version: GNOME2.12.2 0 Gnome-Distributor: Dropline GNOME Synopsis: wnck-applet crashes on dual head display Bugzilla-Product: gnome-panel Bugzilla-Component: Workspace Switcher Applet Bugzilla-Version: 0 BugBuddy-GnomeVersion: 2.0 (2.12.0) Description: Description of the crash: wnck-applet crashes every time natilus is opened on display :0.1 nautilus starts ok, then a message is displayed telling me the wnck-applet has crashed. I click close. After that, all window lists and workspace switchers will crash also and a box appears for each one asking wether it should be reloaded or closed. Steps to reproduce the crash: 1. move mouse pointer to display :0.1 2. click on file browser (nautilus) icon in the panel Expected Results: file browser should open with no problems How often does this happen? about 90% of the time. Depends on what else is already running on that display I think. Additional Information: Other actions also cause the crash. When I log out for instance, wnck-applet crashes usually (90% of the time) just before gdm is re-spawned. Debugging Information: Backtrace was generated from '/usr/libexec/wnck-applet' (no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1225664832 (LWP 21400)] (no debugging symbols found) 0xb7a6e3ee in __waitpid_nocancel () from /lib/tls/libpthread.so.0
+ Trace 65467
------- Bug created by bug-buddy at 2006-01-21 19:03 ------- Unknown version 0 in product gnome-panel. Setting version to "unspecified".
Thanks for the bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Bugsquad: do not close since instructions to reproduce are clear and it might be possible to get a stack trace.
Unfortunately this is all I can generate at the moment (in both bug-buddy and gdb) should I compile a more verbose version somehow?: Backtrace was generated from '/usr/libexec/wnck-applet' (no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (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) [Thread debugging using libthread_db enabled] [New Thread -1226434880 (LWP 9521)] (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) 0xb79b23ee in __waitpid_nocancel () from /lib/tls/libpthread.so.0
+ Trace 65478
I just read up on this and will ask the dropline team for help with this, thanks.
If you can compile a more verbose version, yes, please do it :-)
is this ok? (see backtrace). I noticed that when I start firefox on either display, the startup notification appears in the window list on both displays :0.0 & :0.1 even though I ask it to only show windows from the current desktop. Might that be related, or a small bug? Backtrace was generated from '/usr/libexec/wnck-applet' Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1226086176 (LWP 13143)] 0xb707a3ee in __waitpid_nocancel () from /lib/tls/libpthread.so.0
+ Trace 65534
Stack trace is not helpful either :/ Please see http://live.gnome.org/GettingTraces on how to get a good stack trace. About your question: if you're using your multihead setup as one big screen, then I believe it's expected. If not, then it's probably a bug.
are there too many "??" here? Would I need to add debug symbols to other programs too? Sorry but I've never debugged anything before :/ quote: "if you're using your multihead setup as one big screen," yes I am. to clarify, xorg.conf: Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 Screen 1 "Screen1" rightOf "Screen0" (gdb) thread apply all bt
+ Trace 65535
Thread 1 (Thread -1226106656 (LWP 15051))
I did a "export CFLAGS=-g" and "export CXXFLAGS=-g" before compiling, is that enough? I am using the dropline build system.
Hi again, I made sure that -g was in the cflags by putting it in the dropline config script. Here is what I got (more of the same I'm afraid) with the stuff before the crash too. If it looks like a lost cause then sorry for causing you so much spam ;) By the way, after trying to get it to crash it isn't anywhere near as unstable as I first thought, it takes about 30 clicks on various things to get it to crash after gdb runs it. Starting program: /usr/libexec/wnck-applet [Thread debugging using libthread_db enabled] [New Thread -1226381088 (LWP 16337)] (wnck-applet:16337): Gtk-CRITICAL **: gtk_icon_theme_load_icon: assertion `GTK_IS_ICON_THEME (icon_theme)' failed (wnck-applet:16337): Gtk-CRITICAL **: gtk_icon_theme_load_icon: assertion `GTK_IS_ICON_THEME (icon_theme)' failed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1226381088 (LWP 16337)] 0xb7edb7db in wnck_window_get_transient () from /usr/lib/libwnck-1.so.18 (gdb) thread apply all bt
+ Trace 65539
Thread 1 (Thread -1226381088 (LWP 16337))
Kill the program being debugged? (y or n) y (gdb) q
Yes, new stack traces are still not very useful (lots of ?? is not good). Could you add this patch (in gnome-panel/applets/wncklet) and see if it still happens: http://cvs.gnome.org/viewcvs/gnome-panel/applets/wncklet/window-list.c?r1=1.74&r2=1.75&makepatch=1&diff_format=h It might help for the critical warnings. So, I don't know dropline. Usually, you just have to compile with -g and without -O2 (or -O3) and optimization flags. You might want to ask some dropline people how to get a good stack trace if it doesn't work. Also, libwnck is a good candidate for a debug build too since it's probably involved in the crash. Thanks for being so helpful!
Hi, just to say I am making progress. Have to make glib2-2.8.4 with debugging symbols as well, maybe more. Receiving lots of help from the dropline team and reading lots! - will return
Here's the new backtrace (gnome-panel, libwnk and glib2 all compiled with -g only). A couple of messages I don't understand, "window.c: No such file or directory" and "Previous frame inner to this frame (corrupt stack?)", you have any ideas why they appear?: Starting program: /usr/libexec/wnck-applet [Thread debugging using libthread_db enabled] [New Thread -1226221344 (LWP 9176)] (wnck-applet:9176): Wnck-CRITICAL **: wnck_screen_get_windows: assertion `WNCK_IS_SCREEN (screen)' failed (wnck-applet:9176): Wnck-CRITICAL **: wnck_screen_get_active_window: assertion `WNCK_IS_SCREEN (screen)' failed (wnck-applet:9176): Wnck-CRITICAL **: wnck_screen_get_windows: assertion `WNCK_IS_SCREEN (screen)' failed (wnck-applet:9176): Wnck-CRITICAL **: wnck_screen_get_active_window: assertion `WNCK_IS_SCREEN (screen)' failed (wnck-applet:9176): Wnck-CRITICAL **: wnck_window_get_transient: assertion `WNCK_IS_WINDOW (window)' failed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1226221344 (LWP 9176)] 0xb7f2322d in wnck_window_get_transient (window=0x8183ec0) at window.c:487 487 window.c: No such file or directory. in window.c (gdb) thread apply all bt
+ Trace 65605
Thread 1 (Thread -1226221344 (LWP 9176))
I'm doing libbonobo now ;)
Hi, I *think* I've cracked it: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1225819936 (LWP 4547)] 0xb712c145 in IA__g_type_check_instance_is_a (type_instance=0x817bd10, iface_type=134973976) at gtype.c:3127 3127 gtype.c: No such file or directory. in gtype.c (gdb) thread apply all bt
+ Trace 65606
Thread 1 (Thread -1225819936 (LWP 4547))
Thanks for your work. This crash is already filed here: bug 317333. *** This bug has been marked as a duplicate of 317333 ***