• Diff for "HowToGetABacktrace"

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 install gdb

Installing the debugging symbols

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

deb http://deb.debian.org/debian-debug/ stretch-debug main
deb http://deb.debian.org/debian-debug/ testing-debug main
deb http://deb.debian.org/debian-debug/ unstable-debug main
deb http://deb.debian.org/debian-debug/ experimental-debug main

If you are using Debian buster or later, install debian-goodies and run the find-dbgsym-packages script to find which dbgsym packages to install:

$ find-dbgsym-packages /usr/bin/hello 
hello-dbgsym

Otherwise, 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 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 and skip the rebuilding process in the following instructions and go straight to running gdb.

# apt install hello-dbgsym

Rebuilding the package you’re debugging

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

• 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 apt sources)

# apt install build-essential fakeroot gdb
# apt build-dep hello

• Download & rebuild our package from source, keeping debugging symbols

$ DEB_BUILD_OPTIONS="nostrip noopt" apt -b source hello

• 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_amd64.deb.

# apt install ./hello_2.1.1-4_amd64.deb

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

$ file /usr/bin/hello # output should contain "not stripped"

Running gdb

Batch mode

For including a backtrace in a bug report, you can run this command and then try to reproduce your crash:

$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 'thread apply all bt full' --args hello

Interactively

Use this method if you need to interactively run gdb.

• Now run your program as follows, replacing "[--args]" with any arguments you want to run the program with:

   $ gdb hello
   ... gdb loads ...
   (gdb) set pagination 0
   (gdb) run [--args]
   ... hello loads...

• Then try to reproduce your crash. If you’re lucky, a crash will occur and you’ll be dropped back to the gdb prompt.
• If you are not so lucky to get a crash but instead get a freeze, you can still get gdb prompt by pressing CTRL-C in the terminal running gdb.

• At that point, you can run:

   (gdb) bt

• You’ll then get a lot of output, which you can then copy & paste to a bug followup e-mail or other bug reporting tool.

• When you’re done with gdb, you can just run:

   (gdb) quit

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

• 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):

   (gdb) set logging on

• To check you have debugging symbols in your binary:

   $ gdb
    (gdb) symbol-file /usr/bin/hello
  
   # you should see something like this:
    Reading symbols from /usr/bin/hello ... done
    Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
    (gdb)
  
   # NB you should _not_ see
    Reading symbols from /usr/bin/hello...(no debugging symbols found)...done

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

Other Helpful Links

• Debugging the Xorg server

• Ubuntu Backtrace page

• Debugging GNOME Shell

--AriPollak and ?LoicMinier

CategoryDebugging