Hi I'm using xubuntu 8.04 + compiz + xfdesktop 4.4.2-5ubuntu1 When I right click on the desktop the menu doesn't show, desktop become black with a " kernel: [ 5733.136895] xfdesktop[7828]: segfault at 0000000c eip 0806751b esp bfa1e4d0 error 4 " message on syslog.(esp changes when eip stays the same) when I use xfwm4, I've got the same issue except for the black screen (segfault + no menu)
Please provide a backtrace with debuginfo packages installed for xfdesktop, libxfcegui4, libxfce4util, gtk, and glib.
Hello - I have the sam problem, only it seems very random. I am not sure how to recreate it, but I get the following from dmesg: xfdesktop[3811]: segfault at 0000000c eip 4e319830 esp bfbe77c4 error 4 xfdesktop[12452]: segfault at 0000000c eip 4e319830 esp bfed4af4 error 4 I do know that if you can get back into the Desktop Settings / Preferences, the Allow Xfce4 to manage the display checkbox will be unchecked - rechecl it to restart, but over time, it will segfault again. Mine might also occur on right clicks - I will try to watch more carefully when this happens. If it happens again, I will try to post more exact conditions. Thanks for a great desktop though! I am sorry - I don't quite know how to make a backtrace - if I figure out how, I can try to provide one as well.
Actually, if you're using Ubuntu pacakges, please report this bug to them. They tend to modify our software quite a bit for their packages.
(In reply to comment #3) > Actually, if you're using Ubuntu pacakges, please report this bug to them. > They tend to modify our software quite a bit for their packages. I use gentoo - so from that respect it is a source build. I am more than happy to help - I just need someone to tell me what to do. My guess is that I would build Xfce according to their instructions to get a backtrace, but what I am not sure of is how would I run it - would I just start the Xfce4 with the debugger? Anyway - I will admit I don't know much when it comes to debugging a complex program like this, but I am more than happy to help if I can. Also, I don't think this is triggered by a right click - it seems to happen very randomly. Thanks!
Ok, here's what you'd want to do on Gentoo, then: # emerge -u gdb # vim /etc/make.conf [Add "-g" to CFLAGS if it's not already there] # FEATURES="nostrip" emerge glib gtk libxfce4util libxfcegui4 libexo thunar xfdesktop $ killall xfdesktop $ gdb xfdesktop [....] (gdb) run Leave the terminal open, stick it in a corner, and wait for xfdesktop to crash. When it does, go back to the terminal, type 'bt' at the (gdb) prompt, hit enter, and paste all the goodies into his bug.
hi. sorry for this late answer... in fact I have the problem only on xubuntu..., with a machine on which I installed first ubuntu warty, then xubuntu dapper years ago. Since I updated it, so maybe my case is not revelant, and I should do a fresh install... all my familly and friends are on xubuntu/ubuntu (thank you vnc, ... no more "hey pierre I got a virus on my MS$"), and no one seems to have this pb... with my gentoo box, xfdesktop works just fine and until now, never crashes.... So even if I opened this thread, I think I'm useless here... sorry!
(In reply to comment #5) > Ok, here's what you'd want to do on Gentoo, then: > > # emerge -u gdb > # vim /etc/make.conf > [Add "-g" to CFLAGS if it's not already there] > # FEATURES="nostrip" emerge glib gtk libxfce4util libxfcegui4 libexo thunar > xfdesktop > $ killall xfdesktop > $ gdb xfdesktop > [....] > (gdb) run > > Leave the terminal open, stick it in a corner, and wait for xfdesktop to crash. > When it does, go back to the terminal, type 'bt' at the (gdb) prompt, hit > enter, and paste all the goodies into his bug. Well, I did everything you said, except that when xfdesktop crashes, I can't set focus to the terminal running gdb. Is there some way for me to run gdb in say the tty1 terminal or a key combination I am not aware of to set focus? Here is what I was able to get at the crash (probably not useful without the bt) Program received signal SIGSEV, segmentation fault. [Switching to thread 0xb7a57700 (LWP 3910)] 0x4e319830 in ?? () from /lib/libc.so.6 Sorry - until I figure out a way to grab the terminals focus, I may not be of much help, but if you have any ideas - I am all ears. Thanks!
(In reply to comment #7) > (In reply to comment #5) > > Ok, here's what you'd want to do on Gentoo, then: > > > > # emerge -u gdb > > # vim /etc/make.conf > > [Add "-g" to CFLAGS if it's not already there] > > # FEATURES="nostrip" emerge glib gtk libxfce4util libxfcegui4 libexo thunar > > xfdesktop > > $ killall xfdesktop > > $ gdb xfdesktop > > [....] > > (gdb) run > > > > Leave the terminal open, stick it in a corner, and wait for xfdesktop to crash. > > When it does, go back to the terminal, type 'bt' at the (gdb) prompt, hit > > enter, and paste all the goodies into his bug. > > Well, I did everything you said, except that when xfdesktop crashes, I can't > set focus to the terminal running gdb. Is there some way for me to run gdb in > say the tty1 terminal or a key combination I am not aware of to set focus? > Here is what I was able to get at the crash (probably not useful without the > bt) > > Program received signal SIGSEV, segmentation fault. > [Switching to thread 0xb7a57700 (LWP 3910)] > 0x4e319830 in ?? () from /lib/libc.so.6 > > Sorry - until I figure out a way to grab the terminals focus, I may not be of > much help, but if you have any ideas - I am all ears. > > Thanks! Alt + Tab = let me try that first - I'll get back to you...
I was able to do a core dump and then run gdb /usr/bin/xfdesktop --core core but all I got out of it was: #0 0x4e319830 in ?? () from /lib/libc.so.6 #1 0x00000000 in ?? () Is that what you are looking for? Do I need to compile something else differently? Hope I can continue to help. Thanks again!
Hmm, that's very strange. You aren't compiling with -fomit-frame-pointer, are you? You can also try typing 'info threads' at the prompt... maybe a couple different threads were running. You can type 'thread #' to switch to another thread (replace # with the thread number displayed).
I am not compiling with -fomit-frame-pointer, and I still get the following: (gdb) info threads * 1 process 5182 0x4e319830 in ?? () from /lib/libc.so.6 (gdb) thread 1 [Switching to thread 1 (process 5182)]#0 0x4e319830 in ?? () from /lib/libc.so.6 (gdb) bt #0 0x4e319830 in ?? () from /lib/libc.so.6 #1 0x00000000 in ?? () (gdb) I even rcompiled with -ggdb to try and get some more meningful info. Also, I am still using a core dump. Any suggestions?
Not sure, really weird. It might be a problem with the core dump, but I'd expect that to work ok, as long as the core file matches the xfdesktop binary you run it against. You can try running xfdesktop in gdb from a virtual console -- you can switch to one while in X using ctrl+alt+F2 or whatever. Then just run it from the console after doing 'export DISPLAY=:0' so it knows where to find X. The reason you're losing keyboard input when it crashes in gdb is probably because it does a mouse/keyboard grab when popping up the menu, and since gdb freezes the process when it crashes, the grab doesn't get killed when the app quits.
Created attachment 1789 bactrace for all threads from xfdesktop core dump
I found the problem - I needed to rebuild glibc with the -ggdb option. I added the log of the entire backtrace from the core dump as an attachment. Let me know if I can help some more - or let me know if you need me to help you further investigate. Thanks!
Er, what were you doing when it crashed?
Sorry - I forgot that little detail. I had right clicked to open up the menu, and then just moved the mouse up and down the menu (holding the right mouse button) until it crashed. That is the easiest way to replicate it, but it sometimes just happens randomly or seemingly randomly as well.
Well, the thing is... there shouldn't be any extra threads in the background if all you were doing is opening the menu. The file management library (thunar-vfs) creates a couple threads when doing things like copying and moving files, but they shouldn't be active if you're just playing with the menu. It's hard to tell what's really going on here. Thread 1 is where the menu stuff is happening, and it appears to be crashing inside libxml2, which is *very* surprising given how well-tested and robust libxml2 is. So it's possible the crash is due to earlier memory corruption that takes a while to trigger. Not really sure what to say at this point.
There is one thing I have just noticed - when it shuts down from the menu, it only occurs on the Games menu and only of I leave the mouse there long enough for the next menu to pop up.
Maybe a corrupt menu item?
Probably not a corrupt menu item, as that doesn't use the XML parser. Actually, I'm a bit confused, as I didn't think we were using libxml2 at all anymore. The categories file for the menu is parsed using glib. The menu entry files themselves aren't even XML files. So... I have no idea why your copy of xfdesktop is even linked against libxml2.
Well, unfortunately I don't either :) I guess I could just never play games again!
Would it help if I gave you a less detailed back trace? I don't think rebuilding is going to help since I had to do that when I made the debuggable version.
The other thing I found - and I don't know if this is helpful - is that if I make a menu item in the bottom panel and do the same thing, the panel item will shut down as well.
Yeah, the panel uses the exact same code, so I'm not surprised. Not really sure what else would be of help, sorry.
Hey - thanks for all your help and suggestions. I checked my version of libxml2 and saw that there was one just slightly older. I reverted back and rebuilt - no problem now. Thanks again!
Appears to be related to libxml2... weird.