Reconstruire le paquet que vous deboguez

Install the basic development packages and the build-dependencies for the package we want to rebuild. Note that you can skip the rebuilding part and go straight to running gdb, but it is unlikely that you will get a useful backtrace. (If the build-dep line fails, check you have deb-src lines in /etc/apt/sources.list.)

Install our newly built package(s). There may be multiple .deb packages generated, so make sure to install only the ones you want. In this example, the .deb generated was called hello_2.1.1-4_i386.deb.

# dpkg -i hello_2.1.1-4_i386.deb

You can ensure the binaries installed from your .deb have debugging symbols with the 'file' command, or with gdb itself (see below).

Si le problème semble être dans une librairie majeure telle que libc6, xlibs, ou libgtk2.0-0, 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

Commandes gdb avancées

If the program you’re backtracing is multi-threaded, you might want to get a backtrace for all threads:

(gdb) thread apply all bt

Another thing which is quite helpful to report is what variables were set locally at each point in the stack:

(gdb) bt full

You might want to report the output of the combination of the preceding options:

(gdb) thread apply all bt full

And if this is too much irrelevant output, you might want to keep only a few calls, such as the top 10:

(gdb) thread apply all bt full 10

If you have a large backtrace, you can log gdb output to a file (the default is gdb.txt):