How To Get a Meaningful Backtrace

This page will attempt to explain how to get a meaningful debugging backtrace from a reproducible program crash. For this example, we will rebuild & install the "hello" package so that we keep debugging information.

For reference, a "#" at the beginning of a line means that what follows is a command that has to be executed as root. A "$" at the beginning means that what follows is a command that should be executed as your normal user. A "(gdb)" at the beginning means that you should be typing the rest of the command line at the gdb (GNU Debugger) prompt.

Rebuilding the package you're debugging

NOTE for Debian etch & newer: If the package you're trying to debug includes a -dbg package (e.g. for the hello package, a hello-dbg package exists), you should just be able to install the appropriate -dbg package; skip the rebuilding process in the following instructions and go straight to running gdb.

Running gdb

If the problem seems to be in a major library such as libc6, xlibs, or libgtk2.0-0, you'll want to install the appropriate -dbg package (e.g. libc6-dbg in the case of libc6), and run your program under gdb like this (note the LD_LIBRARY_PATH):

 $ LD_LIBRARY_PATH=/usr/lib/debug gdb hello

Often, you will see a backtrace where one or more of the top lines is in malloc() or g_malloc(). When this happens, chances are your backtrace isn't very useful. The easiest way to find some useful information is to set the environment variable MALLOC_CHECK_ to a value of 2. You can do this while running gdb by doing this:

 $ MALLOC_CHECK_=2 gdb hello

Advanced gdb commands

Debugging X Errors

If the program has received an X error; i.e. you see a message of the form:

The program 'preview1' received an X Window System error.

then you can try running the program with --sync, and break on the gdk_x_error function in order to obtain a backtrace.

--AriPollak and ?LoicMinier