| Summary: | =x11-base/xorg-server-1.7.1 segfaults in the first 5 minutes if not launched via startx | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Raphaël Droz <raphael.droz+floss> |
| Component: | New packages | Assignee: | Gentoo X packagers <x11> |
| Status: | VERIFIED NEEDINFO | ||
| Severity: | critical | CC: | mmokrejs |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
strace session of the X crash
xorg.log after a crash modified startDM.sh xorg log xorg strace xorg freeze backtrace gdb backtrace |
||
|
Description
Raphaël Droz
2009-12-03 16:49:40 UTC
Created attachment 212328 [details]
strace session of the X crash
strace runs while X runs, then opening a new folder in mutt (in X) produced the crash as soon as <enter> is pressed
Please attach the corresponding Xorg.log (and xdm.log files or the relevant to your session manager). Also glxinfo output and test whether glxgears work. On a relative quick glance I haven't seen in your strace output where the server started to shutdown. What I saw is that it writes something to the Xorg.log file. I think -s or which switch can be used to yield longer write() lines recorded by strace (so the messages are not truncated). Created attachment 212442 [details]
xorg.log after a crash
I should also say that my xdm.log doesn't exists as my xdm is slightly modified to let one user autologin. The only modification are : /etc/conf.d/xdm: CHECKVT=7 DISPLAYMANAGER="startx" NEEDS_HALD="yes" My startDM.sh is attached. I can't see any difference susceptible to crash X, anyway ... About the strace I'll attach a more complete one as soon as I can reboot. As a last note, I'am able to consistently reproduce this bug as soon as I 'su' in xterm. Created attachment 212450 [details, diff]
modified startDM.sh
Created attachment 212518 [details]
xorg log
Created attachment 212519 [details]
xorg strace
Xorg crash happens 2 seconds after having launched strace -v -s -ff
(In reply to comment #4) > ... > CHECKVT=7 > ... Anyway I should have precised that X default to tty2 at boot (I wanted to dig this for some time), that's why I see garbage in it (and in auth.log) after the X crash. I removed x11 overlay and masked stuff. So with =x11-base/xorg-server-1.7.3 and mostly stable/~amd64, it still segfault at boot (still not when launched with startx) but in a slighty different manner : it now freezes instead of going back to the previous tty so I have to use sysrq magic to reboot :S 1) drop the -fxxx stuff from your C(XX)FLAGS and rebuild dbus 2) please read this guide [1] and rebuild dbus, libdrm, xorg-server and your X drivers to get a better backtrace in Xorg.0.log Thanks [1] http://www.gentoo.org/proj/en/qa/backtraces.xml (In reply to comment #10) > 1) drop the -fxxx stuff from your C(XX)FLAGS and rebuild dbus Done, it still happens > 2) please read this guide [1] and rebuild dbus, libdrm, xorg-server and your X > drivers to get a better backtrace in Xorg.0.log Done, backtrace attached but not much more useful than previous ones. Note: Xorg froze in a same way this afternoon while started with startx (similar backtrace) Note 2: I can't reproduce the freeze when xinit is loaded in gdb (sad). Created attachment 213791 [details]
xorg freeze backtrace
I suggest to put $(use_enable debug) in the ebuild. I noticed --enable-debug isn't handled in the ebuild nor its eclasses, and isn't a ./configure default, I'll see if it gives better backtraces. Created attachment 214205 [details]
gdb backtrace
ssh/gdb backtrace of Xorg freeze
(In reply to comment #13) > I suggest to put $(use_enable debug) in the ebuild. That has absolutely _nothing_ to do with backtraces. The debug option just enables some debugging paths (which are untested these days) and a few asserts. That's not what I asked in comment #10. Please read the guide again. > I noticed --enable-debug isn't handled in the ebuild nor its eclasses, and > isn't a ./configure default, I'll see if it gives better backtraces. Again, gdb doesn't segfault in the same location. Don't use gdb to debug Xorg unless you know what you're doing. Read the guide again and make Xorg crash. The interesting backtrace will be in Xorg.0.log. Thanks Following the guide :
$ grep FLAG /etc/make.conf
CFLAGS="-O2 -march=native -pipe -ggdb"
CXXFLAGS="${CFLAGS}"
[recompiled X stuff]
$ ps faux # how X is launched
yug 6009 0.0 0.3 19400 1564 ? Ss 17:49 0:00 /bin/sh /usr/bin/startx -- -logverbose 9 -verbose 9 -core
yug 6220 0.0 0.1 15468 940 ? S 17:49 0:00 \_ xinit /home/yug/.xinitrc -- /usr/bin/X -logverbose 9 -verbose 9 -core -auth /home/yug/.serverauth.6009
root 6224 43.7 4.6 102740 23508 tty2 Rs+ 17:49 2:05 \_ /usr/bin/X :0 -logverbose 9 -verbose 9 -core -auth /home/yug/.serverauth.6009
Here two backtraces, quite differents but obtained with the same method :
-------------
Backtrace 1:
0: /usr/bin/X (xorg_backtrace+0x28) [0x46c858]
1: /usr/bin/X (0x400000+0x62879) [0x462879]
2: /lib/libpthread.so.0 (0x7fb920307000+0xea40) [0x7fb920315a40]
3: /lib/libc.so.6 (__select+0x13) [0x7fb91eff34d3]
4: /usr/bin/X (WaitForSomething+0x1aa) [0x46306a]
5: /usr/bin/X (0x400000+0x54482) [0x454482]
6: /usr/bin/X (0x400000+0x24fcb) [0x424fcb]
7: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fb91ef4aa3d]
8: /usr/bin/X (0x400000+0x24b79) [0x424b79]
-------------
Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x46c858]
1: /usr/bin/X (0x400000+0x62879) [0x462879]
2: /lib/libpthread.so.0 (0x7f4175238000+0xea40) [0x7f4175246a40]
3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f4160a4f000+0x2c55) [0x7f4160a51c55]
4: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f4160a4f000+0x55a1) [0x7f4160a545a1]
5: /usr/bin/X (0x400000+0x722b7) [0x4722b7]
6: /usr/bin/X (0x400000+0xff137) [0x4ff137]
7: /lib/libpthread.so.0 (0x7f4175238000+0xea40) [0x7f4175246a40]
8: /usr/bin/X (dixLookupProperty+0x3c) [0x4368ac]
9: /usr/bin/X (0x400000+0x3787a) [0x43787a]
10: /usr/bin/X (0x400000+0x54764) [0x454764]
11: /usr/bin/X (0x400000+0x24fcb) [0x424fcb]
12: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7f4173e7ba3d]
13: /usr/bin/X (0x400000+0x24b79) [0x424b79]
-------------
The -core is passed to Xorg but I can't find any coredump file.
I guess the CWD of start-stop-daemon is used [/etc/X11], but no /etc/X11/core.
$ grep core /etc/security/limits.conf
* soft core 20480
-------------
About the gdb stuff, here is the howto I (wrongly) find useful :
https://wiki.ubuntu.com/X/Backtracing
About the pstack feature, I didn't try but AFAI read it doesn't work with amd64.
I updated to 1.7.4 yesterday and since I'm no more able to reproduce it. I will never know for sure what happened there (my opinion is about something around X (startx/xinit) process backgrounding with start-stop-daemon --background) |
