Ubuntu Wiki

Some tips for debugging the X server.

Debug symbol information

See DebuggingProgramCrash for how to install -dbgsym packages. You will need to install the package xserver-xorg-core-dbgsym, or xserver-xorg-core-dbg on Hardy and the one for your graphic driver xserver-xorg-video-<name>-dbg/sym.

Untrap signals

The X server will by default intercept signals and for instance trap its own crashes and dump a stack trace in /var/log/Xorg.0.log. However, this stack trace is modified by the signal handler itself. To disable this signal interception, add this to your /etc/X11/xorg.conf:

Section "ServerFlags"
        Option "NoTrapSignals" "true"
EndSection

and restart your X server. It is sometimes restarted when logging out, but you can also switch to a text console with Ctrl-Alt-F1, log in and run:

sudo /etc/init.d/gdm restart

You can also run this command remotely, in case you have trouble with your text consoles etc.

Log in remotely

You will want to run the commands in a terminal window on another computer since you will not have access to the local screen and keyboard. This is explained in [https://help.ubuntu.com/community/DebuggingSystemCrash DebuggingSystemCrash]

Backtrace with gdb

Logged in remotely on your "sick" machine, you can now run the gdb debugger on the X server process. First, find the process ID (pid) of Xorg:

pgrep Xorg

Then start gdb and attach to that process:

sudo gdb /usr/bin/Xorg

(gdb starts up and gives you its (gdb) prompt)

(gdb) attach <the process ID you found above>
(gdb) cont

Now do what you need to make the X server crash. Or, if the problem is that the X server is locked up and doesn't react, stop it with ctrl-C. Now get a backtrace:

(gdb) backtrace full

See also BackTrace for more information on this. Note that if the process is already running, you should use the attach pid command instead of run.

You can do a lot of stuff with gdb. See the [http://sourceware.org/gdb/onlinedocs/gdb.html gdb documentation] or for instance [http://www-128.ibm.com/developerworks/library/l-gdb/ one tutorial] out of many.

If you stopped it with ctrl-C, you can let it run again with the continue command:

(gdb) cont

gdb problems

gdb and Xorg don't always work well together. It may help to start Xorg with the options -keeptty -dumbSched

• keeptty allows you to ^C to get into gdb at anytime

• dumpSched stops the smart scheduler interrupting each time you step

For instance, to start Xorg from within gdb (over a ssh connection), start gdb:

sudo gdb /usr/bin/Xorg

inside gdm, start up Xorg:

(gdb) run -keeptty -dumbSched

([http://lists.freedesktop.org/archives/xorg/2007-July/026404.html posted] by Barry Scott on the xorg ML)

Post-mortem backtrace

If the server has died and dumped a core dump, you can get a backtrace from it in the same way. Locate the core dump (usually in /etc/X11/core) and run

sudo gdb /usr/bin/Xorg /etc/X11/core

Then run the "backtrace full" command inside gdb.

If you can't find any core files after a crash, look also in /var/crash, where apport (the automatic crash reporter) leaves its reports. apport interferes with the normal core dumping, so to get a core dump you can also try also to disable apport by editing /etc/default/apport (change disabled= from 1 to 0) and reboot.

Another problem can be that the default maximum size of core files has been set to 0. To avoid this limitation, run ulimit (in the same shell) before restarting the X server:

sudo /etc/init.d/gdm stop
ulimit -c unlimited
sudo /etc/init.d/gdm start

Trace

Instead of, or in addition to, a backtrace, a system call trace or library call trace can be useful in order to see what a runaway process is doing. Find the process ID as explained above and run:

sudo strace -p <pid>

or

sudo ltrace -p <pid>

Stop the trace with ctrl-C. These commands have options to send output to a file, or to filter for particular (classes of) calls, see the manual pages.

DRI / drm problems

More verbose debugging information can be obtained by enabling the debug option of the drm kernel module:

echo 1 | sudo tee /sys/module/drm/parameters/debug

Note that leaving this option on will generate a lot of messages in your /var/log/kern.log and /var/log/syslog! To turn it off again:

echo 0 | sudo tee /sys/module/drm/parameters/debug

Xorg Memory Usage

If you notice Xorg is using large amounts of memory, you can get a better indication of the server-side resource usage of X's client apps via the top-like xrestop program. For reporting issues, the xrestop -b option is handy. For example, xrestop -b -m 5 | grep -A 15 metacity would print 5 samples of resource usage of the window manager, taken 2 seconds apart.

More information

• http://xorg.freedesktop.org/wiki/Development/Documentation/ServerDebugging

• http://wiki.debian.org/XStrikeForce/XserverDebugging