This time, instead of the server crashing, it should freeze, and gdb should tell you the server got a signal (usually SIGSEGV), as well as the function and line of code where the problem happened. Go back to the machine running X, and run your testcase. Notice that the X server has halted type cont at the gdb prompt to continue executing. Gdb will attach to the running server and spin for a while reading in symbols from all the drivers. You can avoid this by passing this option: -keeptty don't detach controlling tty (for debugging only) Note that even when running with a ssh, X might cripples the console.
![startx more verbose startx more verbose](https://i.ytimg.com/vi/_-vTfgfCKI4/hqdefault.jpg)
su root, and type gdb /opt/xorg-debug/Xorg $(pidof Xorg) Go over to your second machine and ssh into the first one.
#STARTX MORE VERBOSE DRIVER#
Remember that if you're trying to debug into a driver, you'll want to repeat this step for the driver as well as for the server core. Be careful of ModulePath and other such path statements in your nf. You may want to put your debuggable server in a different prefix. configure -prefix=.Īll the normal configure options should work as expected. To pass compiler flags in at build time, say: CFLAGS='-O0 -g3'. Otherwise, if you're building X yourself, you'll need to have built X with debugging information.
#STARTX MORE VERBOSE INSTALL#
On Debian or Ubuntu you'd say apt-get install xserver-xorg-core-dbg xserver-xorg-video-ati-dbg For example, on a Fedora machine, you'd say: debuginfo-install xorg-x11-server-Xorg xorg-x11-drv-ati You'll probably want at least the debuginfo for the X server itself, and for the video driver you're using.
#STARTX MORE VERBOSE HOW TO#
Refer to your distro's documentation for details on how to install these. These packages (usually quite large) include the debugging symbols for the software you have installed, which makes tools like gdb much more useful. If you're debugging with a modern distribution, then they probably already have 'debuginfo' packages available.
![startx more verbose startx more verbose](https://i.pinimg.com/474x/04/a7/cd/04a7cd19e2df65f60a35ecb9ba8bfae4.jpg)
![startx more verbose startx more verbose](http://i0.kym-cdn.com/photos/images/masonry/001/205/058/da5.png)
Your gdb needs to be reasonably recent, 5.3 or better is probably good.Īnd of course, you'll need a reproduceable way of crashing the X server, but if you've read this far you've probably got that already. If you don't have a second machine, see the Debugging with one machine section, and good luck. It's very difficult to debug the X server from within itself when it stops and returns control to the debugger, you won't be able to send events to the xterm running your debugger. You'll really want to have a second machine around. Just as a warning, if you try this with a closed-source driver, the output is not likely to be very useful. It assumes a basic familiarity with unix and a willingness to risk deadlocking the machine. This minihowto attempts to explain how to debug the X server, particularly in the case where the server crashes.