Bug 545834

Created attachment 377185 [details]
dmesg output

Looking at some of the other bugs, seems generally you want the dmesg output. Attached...

OK, two backtraces in one log. Nice!

Backtrace:
0: /usr/bin/Xorg (xorg_backtrace+0x3c) [0x80e587c]
1: /usr/bin/Xorg (0x8047000+0x5fb66) [0x80a6b66]
2: (vdso) (__kernel_rt_sigreturn+0x0) [0x5ae40c]
3: /lib/libc.so.6 (0x3cb000+0x70ebd) [0x43bebd]
4: /lib/libc.so.6 (__libc_malloc+0x5e) [0x43d1fe]
5: /usr/bin/Xorg (Xalloc+0x2a) [0x80a770a]
6: /usr/bin/Xorg (Xcalloc+0x26) [0x80a7a76]
7: /usr/bin/Xorg (0x8047000+0xe16f5) [0x81286f5]
8: /usr/bin/Xorg (0x8047000+0xdc3c4) [0x81233c4]
9: /usr/bin/Xorg (0x8047000+0x271f7) [0x806e1f7]
10: /usr/bin/Xorg (0x8047000+0x1b8c5) [0x80628c5]
11: /lib/libc.so.6 (__libc_start_main+0xe6) [0x3e1bb6]
12: /usr/bin/Xorg (0x8047000+0x1b4b1) [0x80624b1]
Segmentation fault at address 0x4000088

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting


Please consult the The X.Org Foundation support 
	 at http://bodhi.fedoraproject.org/
 for help. 
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/Xorg (xorg_backtrace+0x3c) [0x80e587c]
1: /usr/bin/Xorg (mieqEnqueue+0x1b7) [0x80e51a7]
2: /usr/bin/Xorg (xf86PostMotionEventP+0xd4) [0x80bf8a4]
3: /usr/lib/xorg/modules/input/evdev_drv.so (0x278000+0x4602) [0x27c602]
4: /usr/lib/xorg/modules/input/evdev_drv.so (0x278000+0x48f6) [0x27c8f6]
5: /usr/bin/Xorg (0x8047000+0x6b1f0) [0x80b21f0]
6: /usr/bin/Xorg (0x8047000+0x11ed24) [0x8165d24]
7: (vdso) (__kernel_sigreturn+0x0) [0x5ae400]
8: (vdso) (__kernel_vsyscall+0x2) [0x5ae416]
9: /lib/libc.so.6 (0x3cb000+0xe9b83) [0x4b4b83]
10: /lib/libc.so.6 (0x3cb000+0x740d4) [0x43f0d4]
11: /lib/libc.so.6 (0x3cb000+0x70787) [0x43b787]
12: /usr/bin/Xorg (Xfree+0x22) [0x80a7452]
13: /usr/bin/Xorg (0x8047000+0x62b2a) [0x80a9b2a]
14: /usr/bin/Xorg (0x8047000+0x62bb2) [0x80a9bb2]
15: /usr/bin/Xorg (CloseWellKnownConnections+0x34) [0x80a3bf4]
16: /usr/bin/Xorg (0x8047000+0x66ce8) [0x80adce8]
17: /usr/bin/Xorg (0x8047000+0x6734e) [0x80ae34e]
18: /usr/bin/Xorg (0x8047000+0x5fbc0) [0x80a6bc0]
19: (vdso) (__kernel_rt_sigreturn+0x0) [0x5ae40c]
20: /lib/libc.so.6 (0x3cb000+0x70ebd) [0x43bebd]
21: /lib/libc.so.6 (__libc_malloc+0x5e) [0x43d1fe]
22: /usr/bin/Xorg (Xalloc+0x2a) [0x80a770a]
23: /usr/bin/Xorg (Xcalloc+0x26) [0x80a7a76]
24: /usr/bin/Xorg (0x8047000+0xe16f5) [0x81286f5]
25: /usr/bin/Xorg (0x8047000+0xdc3c4) [0x81233c4]
26: /usr/bin/Xorg (0x8047000+0x271f7) [0x806e1f7]
27: /usr/bin/Xorg (0x8047000+0x1b8c5) [0x80628c5]
28: /lib/libc.so.6 (__libc_start_main+0xe6) [0x3e1bb6]
29: /usr/bin/Xorg (0x8047000+0x1b4b1) [0x80624b1]

Anything else I can get from that machine while the Xserver is hung? Any other info you need (lspci, or biosdecode or some such?). Attach to the Xserver with gdb or some other voodoo? I'd like to reboot it before too long...

(In reply to comment #3)
> Anything else I can get from that machine while the Xserver is hung? Any other
> info you need (lspci, or biosdecode or some such?). Attach to the Xserver with
> gdb or some other voodoo? I'd like to reboot it before too long...  

Well, comprehensive (although rather dated) documentation on debugging is http://wiki.x.org/wiki/Development/Documentation/ServerDebugging but I think we have all we can hope for now.

Thank you

*** Bug 545231 has been marked as a duplicate of this bug. ***

I tried playing around a bit with it today. I rebooted to single user, removed /var/log/Xorg.0.log. Then I rebooted normally. Flipped back and forth a few times using the KVM, but it all worked. Then fired up rhythmbox and firefox. Started some music, flipped back to my other machine, and presto, X died (did not hang this time). That took me < 5 minutes. I'll attach the new Xorg.0.log. Let me know if this is more noise than you need.

Created attachment 377438 [details]
Xorg.0.log

I checked the description in Bug 545231, and the observation in that bug that it happens when you switch back to the fedora machine from the alternate machine does not match my experience.

In my case it has happened both switching to the alternate machine from the fedora machine (this AM) as well as switching to the fedora machine from the alternate machine.

After it died again, I now tried it with nothing running (i.e. I logged in, just had the desktop showing, no applications other than what starts with the normal login) and it died after a few tries back and forth.

(In reply to comment #8)
> I checked the description in Bug 545231, and the observation in that bug that
> it happens when you switch back to the fedora machine from the alternate
> machine does not match my experience.
> 
> In my case it has happened both switching to the alternate machine from the
> fedora machine (this AM) as well as switching to the fedora machine from the
> alternate machine.  

Since I upgraded to Fedora 12 and saw the problem occuring, I have always made a point of opening a terminal window on the other machine into Xorg.0.log on the Fedora machine. I have NEVER seen it crash when switching AWAY from the Fedora machine, only when switsching BACK to it.

As I said, that does not match my experience. I did not mean to imply that your observation was incorrect, merely that mine was different.

And as an aside, not sure if I made this clear. I've seen X crash but also hang, including the cursor stopped dead in it's tracks.

The problem here is that we're corrupting malloc's bookkeeping information somewhere along the line.  But we don't notice that until sometime much later, so it's kind of hard to say why it's going wrong.

I don't know if this is relevant, and maybe I shouldn't say it here, but this snippet of information may help:

Using the 'closed' nvidia driver, if I got such a crash on returning the KVM to the linux machine and then I went back to the other machine which (as I said before) was running a terminal and logged in as root, then doing the following got me back 'on my feet' (with a login screen):

telinit 3
kill -9 <whatever the pid of Xorg was - it was always there with ps uax>
telinit 5

HOWEVER, there was always a small black 'tooth' which appeared at the top of the screen. The black area would get onto any window furniture that crossed its path.
Repeatedly fixeg up crashes in this manner made more such 'teeth' appear.

Created attachment 380708 [details]
Xorg logfile

Created attachment 380709 [details]
dmesg output

I do experience the exact same problems with my KVM setup.
I did attach an Xorg.log from toays last crash and dmesg output. Let me know if theres anything else I can get you.

$ X -version

X.Org X Server 1.7.1
Release Date: 2009-10-23
X Protocol Version 11, Revision 0
Build Operating System:  2.6.18-164.2.1.el5 
Current Operating System: Linux dhara 2.6.31.9-174.fc12.x86_64 #1 SMP Mon Dec 21 05:33:33 UTC 2009 x86_64
Kernel command line: ro root=UUID=1df63ef9-4753-407d-a5ac-35bc9ad939a5  LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=de-latin1-nodeadkeys rhgb quiet
Build Date: 19 November 2009  09:25:35PM
Build ID: xorg-x11-server 1.7.1-9.fc12 
Current version of pixman: 0.16.4
	Before reporting problems, check http://bodhi.fedoraproject.org/
	to make sure that you have the latest version.

cheers

Any update on this bug?

I am experiencing this bug. As a possible work around I am using using KDE rather than Gnome and I have not yet observed the lock up where as it was happening virtually every time that I switched back to Fedora 12 running Gnome

*** This bug has been marked as a duplicate of bug 540584 ***