Running xorg-server-1.7.4 produces a segmentation fault which kills the X-session. I don't recall the exact context (I may qualify more after reviewing more logs). It is likely to be either (a) switching VTs or (b) trying to get xrandr to split a gnome session across 2 screens on different hardware (Intel 915 and Radeon 3450 DVI). Reproducible: Always Steps to Reproduce: 1. Build xorg-server-1.7.4. 2. Run it on 3-4 VTs. 3. Use it for a while (switching VTs from time to time) or try to get xrandr to split the gnome session across 2 screens across 2 pieces of hardware). [1.7.4 and earlier versions with xrandr will split (wide screen) a gnome session across the Radeon DVI & VGA channels.] Actual Results: Xorg crashes with a backgrace in the log file (attached). Expected Results: 1. Xorg should not crash (because restoring complex sessions can take 30-60 minutes). 2. Xorg should provide better strack traces. There should be a gdb library which produces high quality stack traces which can be linked into the xorg-server. The current backtrace technology in the server is extremely primitive. 3. Gentoo should provide explicit documentation on how to run xorg-server via gdb. The provided "backtraces.xml" isn't of any use if people can't figure out how to get gdb talking to a console and Xorg talking to an unused VT (such that one gets a login screen, can start a gnome session, work normally, but then have the debugger activated when X segfaults). I suspect a specific command line and some special xinitrc code is required but in spite of several searches I've never managed to unearth this information. (There was a period about a year ago when crashing the X server was an every other day occurrence when this would have been useful.) More xorg-1.7.4 bugs to come.
Created attachment 216726 [details] Xorg.1.log with backtrace of SEGV Not very useful: Backtrace: 0: /usr/bin/X (xorg_backtrace+0x3c) [0x80ecd7c] 1: /usr/bin/X (0x8048000+0x60fef) [0x80a8fef] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xb776040c] 3: /usr/bin/X (0x8048000+0x139123) [0x8181123] 4: /usr/bin/X (0x8048000+0x1394ec) [0x81814ec] 5: /usr/bin/X (xf86Wakeup+0x53c) [0x80b65ed] 6: /usr/bin/X (WakeupHandler+0x4b) [0x806f521] 7: /usr/bin/X (WaitForSomething+0x19b) [0x80a9813] 8: /usr/bin/X (0x8048000+0x25727) [0x806d727] 9: /usr/bin/X (0x8048000+0x1d94a) [0x806594a] 10: /lib/libc.so.6 (__libc_start_main+0xe6) [0xb7221bb6] 11: /usr/bin/X (0x8048000+0x1d521) [0x8065521] Segmentation fault at address 0x13 Xorg needs to use the gdb backtrace capability to print function arguments. The server, driver and all associated system libraries are now produced using splitdebug on my system -- so quality stack traces *could* be produced.
Created attachment 216728 [details] emerge --info Additional information: xorg-server-1.7.4, xf86-video-intel-2.10.0, xf86-video-radeonhd-1.3.0
You can get better backtraces with Xorg by following this guide [1]. That will definitely help. Please rebuild xorg-server, libdrm and all your X drivers. Thanks [1] http://www.gentoo.org/proj/en/qa/backtraces.xml
I have read the backtraces.xml document several times and have gained quite a bit of experience using gdb and routinely use it to debug hung both gdb (and strace) to monitor hung galeon sessions, excessive CPU-use Firefox sessions and large chromium session restores which cease to talk to the X server. I have also filed bug reports in the Gnome, Mozilla and Chrome databases, providing complete gdb strack traces (thread apply bt all, info reg, and even in some cases isolating the precise code in the Gtk libraries responsible for the XID collision problem and Firefox generating Segfaults (the long running "Window unexpectedly destroyed" problem). However, all of these programs are user programs which can be run with GNOME Bug Buddy disabled and can be dealt with from the shell level when one want to trace or startup GDB on them. They also produce core dumps that can be debugged (at least if you have the dump size limits set high enough and the disk space available to support a 1-2 GB core dump (for large Firefox sessions). Nowhere in backtraces.xml is there any commentary on "How to debug Xorg". Nor is there any commentary on how to disable the Xorg primitive signal catching and backtracing and force it to produce a core dump (or where these core dumps will be produced). The only solution I can imagine is to startup all of the Xorg's on VTs (I normally use at least 3), then immediately after they have started, to take 3 console sessions (tty[234]) and startup gdb sessions on each of the Xorg's hoping that at some point one of them will Segfault. [Presumably one cannot startup gdb sessions in gnome-terminals because they might be under the Xorg that fails.] Is this what you are suggesting? [And if so, why isn't *that* documented in backtraces.xml???] Or if there is a way to create a GdbXdbg file which autosets the signal required "pass" requirements in Xorg turns logging on and runs the Xorg servers (e.g. gdb -x GdbXdbg /usr/bin/Xorg) then why isn't an example of that Xservers file provided in backtraces.xml? (the problem I foresee is that of having to fully automate the gdb session so one doesn't need to deal with the issue of gdb instances talking to specific terminals)] Ever since Gentoo implemented splitdebug most of my system libraries and most of the problematic programs (e.g. Firefox, Chromium, etc.) are all compiled using -ggdb and splitdebug. Of course this includes Xorg and all of the X libraries, the gdk/gtk/glib libraries, the various X libraries and the various xf86-xyxxy libraries.
reopening
1) that's a dupe of your other bugs. 2) Xorg uses the standard backtrace() system call, I'm sure upstream would love better patches for to improve this feature. 3) http://www.x.org/wiki/Development/Documentation/ServerDebugging It is more or less known that debugging X with only one box is nearly impossible, there's very little to improve this simple fact. Shame. Thanks
