FS#25323 - [xorg-server] 1.10.3-1 aborts after Fatal server error.

Attached to Project: Arch Linux
Opened by vicencb (vicencb) - Saturday, 30 July 2011, 10:45 GMT
Last edited by Jan de Groot (JGC) - Monday, 10 October 2011, 10:36 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
xorg X server stops running and the system returns to the text-mode console.
This happens after a random time of usage.
The log reports:
-------------------------
Backtrace:
0: X (xorg_backtrace+0x26) [0x45d446]
1: X (0x400000+0x61869) [0x461869]
2: /lib/libpthread.so.0 (0x7fc68d385000+0xf7e0) [0x7fc68d3947e0]
3: /lib/libc.so.6 (__select+0x13) [0x7fc68c3afc03]
4: X (WaitForSomething+0x19b) [0x45afab]
5: X (0x400000+0x2e812) [0x42e812]
6: X (0x400000+0x22b9e) [0x422b9e]
7: /lib/libc.so.6 (__libc_start_main+0xed) [0x7fc68c30317d]
8: X (0x400000+0x22e8d) [0x422e8d]

Fatal server error:
Caught signal 3 (Quit). Server aborting
-------------------------

The full Xorg log is attached.
Don't know if the problem is from Archlinux or upstream.
If further steps are required to get the bug triaged I'll help.
   Xorg.0.log.old (44.9 KiB)
This task depends upon

Closed by  Jan de Groot (JGC)
Monday, 10 October 2011, 10:36 GMT
Reason for closing:  Not a bug
Additional comments about closing:  VT conflict issue again...
Comment by vicencb (vicencb) - Tuesday, 02 August 2011, 21:43 GMT
After reporting the problem I compiled a new version of xorg-server [1.10.3-2] whith "--enable-debug" at the configure script.
Since then I experienced several X stops but without a backtrace until today. Today I was running the updated mesa 7.11-1 with new graphics drivers.
The backtrace is similar, but with diferent values for pointers. The new information is due to the --enable-debug option.
Attached is the log.
   Xorg.0.log.old (100.5 KiB)
Comment by Jan de Groot (JGC) - Tuesday, 02 August 2011, 21:46 GMT
Your log indicates X is running on VT2. How do you start X? If agetty launches on VT2 when X has already taken that console, then you'll face these problems.
Comment by vicencb (vicencb) - Tuesday, 02 August 2011, 23:16 GMT
That is the probable cause of the problem. I'm starting the X session without display manager. At rc.conf there are several services started in the background and a race condition will explain the random nature of the problem.
There are 2 agetty so the second one is at the same VT.
Now I'm running the X session on VT7, if the problem does not repeat then that would be the issue. I will let you know after two or three days of testing.

Thanks.
Comment by vicencb (vicencb) - Friday, 05 August 2011, 21:44 GMT
After 3 days of usage the bug has not reproduced, so agetty must be the cause of the problem.
In any case I'm still thinking that the bug report is valid (with low severity). If the VT gets occupied by a first client then it should become locked. If afterwards a second client tries to use the same VT it should receive a busy error.
Am I correct?

Thanks.
Comment by Artem (sapfeer) - Wednesday, 17 August 2011, 07:31 GMT
I'm facing the same problem. Could anyone point how to make X server start on VT7?..
Comment by vicencb (vicencb) - Wednesday, 17 August 2011, 13:55 GMT
Add a '.xserverrc' file at your home directory containing:
#!/bin/sh
exec X :0 vt7

For more information or other ways: 'man xinit', 'man xorg'
Comment by Artem (sapfeer) - Wednesday, 17 August 2011, 14:04 GMT
Thanks for reply! I've already done it by installing SLiM - now my X server starts at VT7 and doesn't crash anymore
Comment by Artem (sapfeer) - Thursday, 18 August 2011, 04:34 GMT
Thanks for reply! I've already done it by installing SLiM - now my X server starts at VT7 and doesn't crash anymore
Comment by Artem (sapfeer) - Thursday, 18 August 2011, 05:56 GMT

Loading...