Reporting Xorg server crashes

The reportbug application sends most of the needed information (reportbug-ng should be avoided for now since it does NOT do so). Please do not remove anything, it is always better to have useless information than to miss useful information. If for some reason, this information did not get included, you can generate it with

/usr/share/bug/xserver-xorg-core/script 3>&1

This command should be run as root. Be careful with redirections if you're using sudo. For instance, sending the output in a file would be

sudo bash -c "/usr/share/bug/xserver-xorg-core/script 3>&1" > file

The most important part is Xorg log (stored in /var/log/Xorg.0.log for display 0). Every time the X server on display 0 is restarted, the log of the previous session is renamed into Xorg.0.log.old. So you have to make sure you include the latter if you restarted X since the crash.

It is often better to not use xdm|gdm|kdm when debugging the X server since they will try to restart X several times after a failure. Stopping them and starting X by hand is often better:

invoke-rc.d kdm|gdm|xdm stop # as root
startx [/path/to/client/if/any] # as normal user

To get more info on reporting bugs, please look at Reporting Bugs in Debian.

Which debugging packages do I need?

Apart from the log and configuration, debugging a crash of the server requires a detailed backtrace so that developers may know exactly where/when the crash occurs. In order to get this valuable info you need debugging packages to help gdb translate the backtrace into a very detailed backtrace.

First, make sure that the xserver-xorg-core-dbg package is installed.

You should also install a debugging package for your video driver if it is available. For the main video drivers these are the packages xserver-xorg-video-intel-dbg, xserver-xorg-video-ati-dbg and xserver-xorg-video-nouveau-dbg, respectively.

Also, the Mesa/GL libraries might be involved, installing libgl1-mesa-dri-dbg and libgl1-mesa-glx-dbg might help too.

If you think you miss some debugging packages, you might want to rebuild one package with debugging enabled, see HowToGetABacktrace.

Obtaining a backtrace with gdb

Please read this section entirely before actually trying to attach a gdb

Note that you must have root permissions (either running as root or using sudo) to do the following. Attaching gdb to X server before reproducing the crash might catch a nice backtrace:

gdb -p $(pidof X)
(inside gdb)
set logging overwrite on
set logging on
(X server is stopped from when gdb is attached until "continue" is typed)
(do whatever caused the problem)
bt full
set logging off

After this, you get the gdb output in file gdb.txt in the directory where you started gdb (this is what the logging commands did, another solution is to copy-paste the output yourself). Add all this to your bug report, developers will appreciate it. If the backtrace is small, you probably miss several debugging packages, see above.

However, you should NOT do it from a terminal running within X since the crash of the server will kill all X clients, including this terminal and the gdb. A possible solution consists of placing gdb in a virtual console (for instance, the one you get with Ctrl-Alt-F1). However, since the server is involved during the switch between X and this console, it might be impossible to switch once the crash occurs, making your gdb impossible to reach.

The best way is definitely to logon the machine from another machine by ssh and attach gdb from there. Unfortunately, you need another machine to do so, and ssh access.

Also, note that you might have to tell the server to stop catch signals on crash, it should be done by adding:

Option "NoTrapSignals"

in the ServerLayout section of your xorg.conf configuration file.

One user reported that the following line worked without ssh:

# gdb -p $(pidof X) -batch -ex 'handle all nostop' -ex 'handle all pass'
  -ex 'handle 11 stop' -ex 'cont' -ex 'bt full' -ex 'cont'

Obtaining a backtrace from a coredump

If the above solutions are not possible for you or do not work, another way to obtain a backtrace is to let the crash generate a coredump, and run gdb on it later. Debugging packages are required too (xserver-xorg-core-dbg and the drivers' ones too, see the relevant section above).

The command needed to enable core dumps is "ulimit -c unlimited" but this should be run before Xorg is run, and in the same session. You could run it (as root) on a text console, and then (without leaving the session) restart the graphical session (either with startx or invoke-rc.d kdm|gdm|xdm restart) or alternatively you can tweak the kdm|gdm|xdm init script to add the ulimit line.

Once core dumps are enabled you will have the one for Xorg on the file /etc/X11/core. Using gdb, you should have the backtrace info you have to do the following (as root):

cd /etc/X11
gdb $(which Xorg) core
(inside gdb)
set logging overwrite on
set logging on
bt full
set logging off

After this, you get the gdb output in file /etc/X11/gdb.txt. Add all this to your bug report, developers will appreciate it.

Xorg real debugging

The explained method hopefully provides info enough to Xorg Maintainers in order to know where the problem could be but if you would like to debug the Xorg server yourself you could pay attention to Xorg Server Debugging