Translation(s): English - Русский

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 install the package with debugging symbols for "hello" or if this is not available 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 (or sudo). 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.

 # apt-get install gdb

Installing the debugging symbols

Make sure you have the AutomaticDebugPackages archive listed in your ?SourceList (pick the one for your release):

 deb stretch-debug main
 deb testing-debug main
 deb unstable-debug main
 deb experimental-debug main

To see if the package you’re trying to debug includes a -dbgsym or -dbg package (e.g. for the hello source package, a hello-dbgsym or hello-dbg package exists), search for it in your package manager. On the command line you can use the following command.

 $ apt-cache search hello | grep dbg
 p   hello-dbgsym            - Debug symbols for hello

If that doesn't have your debug package either, you could try to rebuild the package as explained in the next section. If an appropriate package was found you should just be able to install the appropriate debug package for example with

 # apt-get install hello-dbgsym

and skip the rebuilding process in the following instructions and go straight to running gdb.

Rebuilding the package you’re debugging

You may skip this section if you were able to install the necessary -dbg package(s) from the previous section.

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 then run the problematic program again under gdb.

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 a GTK 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, thus:

 (gdb) break gdk_x_error
 (gdb) run --sync

--AriPollak and ?LoicMinier