Debug - Getting Traces - ArchWiki

# Debug - Getting Traces

Related articles

- General troubleshooting
- Reporting Bug Guidelines
- Step By Step Debugging Guide

This article aims to help in creating a debugging Arch package and using it to provide trace and debug information for reporting software bugs to developers.

## Package names

This article or section needs language, wiki syntax or style improvements.

Reason: "call the function", "stack trace", gdb is only mentioned later in the article -> unclear introduction (Discuss)

When looking at debug messages, such as:

    [...]
    Backtrace was generated from '/usr/bin/epiphany'

    (no debugging symbols found)
    Using host libthread_db library "/lib/libthread_db.so.1".
    (no debugging symbols found)
    [Thread debugging using libthread_db enabled]
    [New Thread -1241265952 (LWP 12630)]
    (no debugging symbols found)
    0xb7f25410 in __kernel_vsyscall ()
    #0  0xb7f25410 in __kernel_vsyscall ()
    #1  0xb741b45b in ?? () from /lib/libpthread.so.0
    [...]

`??` shows where debugging info is missing, as well as the name of library or executable which called the function. Similarly, when `(no debugging symbols found)` appears, you should look for the stated file names. For example, with pacman:

    # pacman -Qo /lib/libthread_db.so.1
    /lib/libthread_db.so.1 is owned by glibc 2.5-8

The package is called glibc in version 2.5-8. Repeat this step for every package that needs debugging.

## PKGBUILD

In order to build a package from source, the PKGBUILD file is required. See ABS for packages in the official repositories, and AUR#Acquire_build_files for packages in the AUR.

## Compilation settings

At this stage, you can modify the global configuration file of `makepkg` if you will be using it only for debug purposes. In other cases, you should modify package's PKGBUILD file only for each package you would like to rebuild.

### General

As of pacman 4.1, `/etc/makepkg.conf` has debug compilation flags in `DEBUG_CFLAGS` and `DEBUG_CXXFLAGS`. To use them, enable the `debug` makepkg option, and disable `strip`.

    OPTIONS+=(debug !strip)

These settings will force compilation with debugging information and will disable the stripping of executables. (If you do not disable `strip`, debugging information will be generated anyway, but moved to a separate `foo-debug` package).

To apply this setting to a single package, modify the PKGBUILD:

    options=(debug !strip)

Note that certain packages such as glibc are stripped regardless. Check the PKGBUILD for sections such as:

    strip $STRIP_BINARIES usr/bin/{gencat,getconf,getent,iconv,iconvconfig} \
                          usr/bin/{ldconfig,locale,localedef,nscd,makedb} \
                          usr/bin/{pcprofiledump,pldd,rpcgen,sln,sprof} \
                          usr/lib/getconf/*
    [[ $CARCH = "i686" ]] && strip $STRIP_BINARIES usr/bin/lddlibc4

    strip $STRIP_STATIC usr/lib/*.a

    strip $STRIP_SHARED usr/lib/{libanl,libBrokenLocale,libcidn,libcrypt}-*.so \
                        usr/lib/libnss_{compat,db,dns,files,hesiod,nis,nisplus}-*.so \
                        usr/lib/{libdl,libm,libnsl,libresolv,librt,libutil}-*.so \
                        usr/lib/{libmemusage,libpcprofile,libSegFault}.so \
                        usr/lib/{audit,gconv}/*.so

And remove them where appropriate.

### Qt

In addition to the previous general settings, pass `-developer-build` option to the `configure` script in the `PKGBUILD`. By default, `-developer-build` passes `-Werror` to the compiler, which may cause the compilation to fail. To avoid compilation errors, you may need pass `-no-warnings-are-errors`, too.

This article or section needs language, wiki syntax or style improvements.

Reason: Recommending ignore-deps is dubious (Discuss)

Note:

Compiling Qt with qtwebkit installed may cause compilation errors. Hence, remove qtwebkit package temporarily from your system. Use the following command in order to ignore any dependencies on qtwebkit.

    # pacman -Rdd qtwebkit

Do not forget to install qtwebkit after the compilation of Qt is finished, otherwise the programs that depend on it will not work!

### KDE applications

KDE and related programs typically use cmake. Change `-DCMAKE_BUILD_TYPE` to `Debug`.

## Building and installing the package

Build the package from source using `makepkg` while in the PKGBUILD's directory. This could take some time:

    # makepkg

Then install the built package:

    # pacman -U glibc-2.5-8-i686.pkg.tar.gz

## Getting the trace

This article or section needs expansion.

Reason: Mention core dumps (Discuss)

The actual backtrace (or stack trace) can now be obtained via e.g. gdb, the GNU Debugger. Run it either via:

    # gdb /path/to/file

or:

    # gdb
    (gdb) exec /path/to/file

The path is optional, if already set in the `$PATH` variable.

Then, within `gdb`, type `run` followed by any arguments you wish the program to start with, e.g.:

    (gdb) run --no-daemon --verbose

to start execution of the file. Do whatever necessary to evoke the bug. For the actual log, type the lines:

    (gdb) set logging file trace.log
    (gdb) set logging on

and then:

    (gdb) thread apply all bt full

to output the trace to `trace.log` into the directory `gdb` was started in. To exit, enter:

    (gdb) set logging off
    (gdb) quit

Tip: To debug an application written in python:

    # gdb /usr/bin/python
    (gdb) run <python application>

You can also debug an already running application, e.g.:

     # gdb --pid=$(pidof firefox)
     (gdb) continue

## Conclusion

Use the complete stack trace to inform developers of a bug you have discovered before. This will be highly appreciated by them and will help to improve your favorite program.

## See also

- Gentoo Linux Documentation — How to get meaningful backtraces in Gentoo
- Fedora - StackTraces
- GNOME - Getting Stack Traces
- gdb mini intro

Category:

- Package development