Difference between revisions of "Debug - Getting Traces"

From ArchWiki
Jump to: navigation, search
(Global settings: mentioning 64-bit architecture)
(/etc/makepkg-debug.conf example)
 
(41 intermediate revisions by 15 users not shown)
Line 1: Line 1:
[[zh-CN:Debug - Getting Traces]]
 
 
[[Category:Package development]]
 
[[Category:Package development]]
 +
[[ja:デバッグ - トレースを取得]]
 +
[[ru:Debug - Getting Traces]]
 +
[[zh-cn:Debug - Getting Traces]]
 +
{{Related articles start}}
 +
{{Related|General troubleshooting}}
 +
{{Related|Reporting bug guidelines}}
 +
{{Related|Step-by-step debugging guide}}
 +
{{Related articles end}}
 
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.
 
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.
  
==Discovering name of package(s)==
+
== Package names ==
===A few facts of debug messages===
+
 
When looking at debug message, such as:
+
{{Poor writing|"call the function", "stack trace", gdb is only mentioned later in the article -> unclear introduction}}
+
 
 +
When looking at debug messages, such as:
 +
 
 
  [...]
 
  [...]
 
  Backtrace was generated from '/usr/bin/epiphany'
 
  Backtrace was generated from '/usr/bin/epiphany'
Line 21: Line 30:
 
  [...]
 
  [...]
  
you can see {{ic|??}} at the place where debugging info is missing and also the name of library or executable which called the function. Similarly, when the line {{ic|(no debugging symbols found)}} appears in a message, it means that you have to look for a file whose name is stated.  
+
{{ic|??}} shows where debugging info is missing, as well as the name of library or executable which called the function. Similarly, when {{ic|(no debugging symbols found)}} appears, you should look for the stated file names. For example, with [[pacman]]:
 
+
===Finding package===
+
Use [[Pacman]] to retrieve name of package:
+
  
 
  # pacman -Qo /lib/libthread_db.so.1
 
  # pacman -Qo /lib/libthread_db.so.1
 
  /lib/libthread_db.so.1 is owned by ''glibc'' 2.5-8
 
  /lib/libthread_db.so.1 is owned by ''glibc'' 2.5-8
  
We have found that package is called {{Pkg|glibc}} in version 2.5-8. By repeating this step, we are able to create a list of packages which we have to compile ourselves to get full stack trace.
+
The package is called {{Pkg|glibc}} in version 2.5-8. Repeat this step for every package that needs debugging.
  
==Obtaining PKGBUILD==
+
== PKGBUILD ==
In order to build a package from source, the PKGBUILD file is required. The location from which you can obtain PKGBUILDs is, in general:
+
#[[AUR]] or
+
#[[ABS]]
+
  
===Using AUR===
+
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]].
Use [https://aur.archlinux.org/packages.php AUR search page] to find the package. If it is not present, the package is stored in one of the official repository trees of Arch Linux. If found, click on its name and download the {{ic|Tarball}}. Use {{ic|tar}} to extract it and change the directory:
+
  
$ tar xvzf name_of_tarball.tar.gz
+
== Compilation settings ==
$ cd name_of_tarball
+
  
===Using ABS===
+
At this stage, you can modify the global configuration file of {{ic|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.
If the package is a part of official tree, install [[ABS]], fetch the source for the package and then build it:
+
  
$ ABSROOT=. abs core/glibc
+
=== General ===
$ cd core/glibc
+
$ makepkg -s
+
  
==Compilation settings==
+
As of pacman 4.1, {{ic|/etc/makepkg.conf}} has debug compilation flags in {{ic|DEBUG_CFLAGS}} and {{ic|DEBUG_CXXFLAGS}}. To use them, enable the {{ic|debug}} makepkg option, and disable {{ic|strip}}.
At this stage, you can modify the global configuration file of {{ic|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.
+
===Global settings===
+
Modify {{ic|makepkg}}'s configuration file {{ic|/etc/makepkg.conf}} to contain following lines:
+
  
  CFLAGS="'''-g''' -march=i686 '''-O1''' -pipe"
+
  OPTIONS+=(debug !strip)
CXXFLAGS="'''-g''' -march=i686 '''-O1''' -pipe"
+
  
(change i686 with x86-64 if using 64-bit system)
+
These settings will force compilation with debugging information and will disable the stripping of debug symbols from executables. To apply this setting to a single package, modify the PKGBUILD:
  
and:
+
  options=(debug !strip)
   
+
OPTIONS=('''!strip''' !docs libtool emptydirs)
+
  
These settings (in bold) will force compilation with debugging information and will disable the stripping of executables.
+
Alternatively you can put the debug information in a separate package by enabling both {{ic|debug}} and {{ic|strip}}, debugging information will then be stripped from the main package and placed in a separate {{ic|''foo''-debug}} package.
  
===One package settings only===
+
It is possible to have a separate config for your debug builds that will load the default config and alter some variables. This way you can create debug builds only when you need to and without editing PKGBUILD or configuration files each time.
Modify {{ic|foo}}'s PKGBUILD file to contain the following lines:
+
  
options=(!strip)
+
{{bc|<nowiki>
 +
. /etc/makepkg.conf
  
Into the {{ic|build()}} function, add following lines at the very beginning:
+
cmake() {
 +
  command cmake -DCMAKE_BUILD_TYPE=Debug "$@"
 +
}
  
export CFLAGS="$CFLAGS -g -O1"
+
_remove_opt() {
export CXXFLAGS="$CXXFLAGS -g -O1"
+
local newarr=()
 +
for el in "${OPTIONS[@]}"; do
 +
case $el in
 +
"$1") ;;
 +
*) newarr+=( "$el" );;
 +
esac
 +
done
 +
OPTIONS=( "${newarr[@]}" )
 +
}
  
{{Note|A change in optimization level below {{Ic|-O1}} cannot be generally recommended as {{ic|gcc}} then uses implementations of functions in the GNU C library that can be considered too different from the optimized ones. Also, changes in headers' includes and disabled functions may prevent successful compilation.}}
+
_remove_opt strip
 +
_remove_opt !strip
 +
_remove_opt debug
 +
_remove_opt !debug
 +
OPTIONS=( "${OPTIONS[@]}" !strip debug )
 +
</nowiki>}}
  
===Qt===
+
Save it into {{ic|/etc/makepkg-debug.conf}} and use the  it like this:
In addition to the previous general settings you should pass {{ic|-developer-build}} option to the {{ic|configure}} script in the {{ic|PKGBUILD}}. Also compiling Qt with qtwebkit installed may cause compilation errors. That is why you would also want to remove qtwebkit package temporarily from your system. Use the following command in order to ignore any dependencies on qtwebkit.
+
 
+
  makepkg --config /etc/makepkg-debug.conf ...
# pacman -Rdd qtwebkit
+
 
 +
 
 +
{{Note|It is insufficient to simply install the newly compiled debug package, because the debugger will check that the file containing the debug symbols is from the same build as the associated library and executable. You must install both of the recompiled packages. In Arch, the debug symbols files are installed under {{ic|/usr/lib/debug}}. See the [https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html GDB documentation]
 +
for more information about debug packages.}}
 +
 
 +
Note that certain packages such as ''glibc'' are stripped regardless. Check the PKGBUILD for sections such as:
 +
 
 +
{{bc|<nowiki>
 +
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
 +
</nowiki>}}
 +
 
 +
And remove them where appropriate.
 +
 
 +
=== Qt4 ===
 +
 
 +
In addition to the previous general settings, pass {{ic|-developer-build}} option to the {{ic|configure}} script in the {{ic|PKGBUILD}}. By default, {{ic|-developer-build}} passes {{ic|-Werror}} to the compiler, which may cause the compilation to fail. To avoid compilation errors, you may need pass {{ic|-no-warnings-are-errors}}, too.
 +
 
 +
=== Qt5 ===
 +
 
 +
The [[Unofficial_user_repositories#qt-debug|qt-debug]] repository contains pre-built Qt/PyQt packages with debug symbols. See also [http://doc.qt.io/qt-5/debug.html upstream] instructions.
 +
 
 +
=== CMAKE (KDE) applications ===
  
Do not forget to install qtwebkit after the compilation of Qt is finished, otherwise the programs that depend on it will not work!
+
[[KDE]] and related programs typically use {{Pkg|cmake}}. To enable debug information and disable optimisations, change {{ic|-DCMAKE_BUILD_TYPE}} to {{ic|Debug}}.
 +
To enable debug information while keeping optimisations enabled, change {{ic|-DCMAKE_BUILD_TYPE}} to {{ic|RelWithDebInfo}}.
  
===KDE applications===
+
== Building and installing the package ==
KDE and software built with KDE technologies normally use CMake for build. To build this software with debug symbols change the option {{ic|-DCMAKE_BUILD_TYPE}} to {{ic|Debug}}.
+
  
==Building and installing the package==
 
 
Build the package from source using {{ic|makepkg}} while in the PKGBUILD's directory. This could take some time:
 
Build the package from source using {{ic|makepkg}} while in the PKGBUILD's directory. This could take some time:
  
Line 96: Line 135:
 
  # pacman -U glibc-2.5-8-i686.pkg.tar.gz
 
  # pacman -U glibc-2.5-8-i686.pkg.tar.gz
  
==Getting the trace==
+
== Getting the trace ==
 +
 
 +
{{Expansion|Mention core dumps}}
  
 
The actual backtrace (or stack trace) can now be obtained via e.g. {{Pkg|gdb}}, the GNU Debugger. Run it either via:
 
The actual backtrace (or stack trace) can now be obtained via e.g. {{Pkg|gdb}}, the GNU Debugger. Run it either via:
Line 120: Line 161:
 
and then:
 
and then:
  
  (gdb) bt
+
  (gdb) thread apply all bt full
  
 
to output the trace to {{Ic|trace.log}} into the directory {{Ic|gdb}} was started in. To exit, enter:
 
to output the trace to {{Ic|trace.log}} into the directory {{Ic|gdb}} was started in. To exit, enter:
Line 132: Line 173:
 
}}
 
}}
  
==Conclusion==
+
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.
 
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 ==
 
== See also ==
*[[Reporting Bug Guidelines]]
+
 
*[[Step By Step Debugging Guide]]
+
* [https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces Gentoo Wiki - Backtraces with Gentoo]
*[http://www.gentoo.org/proj/en/qa/backtraces.xml Gentoo Linux Documentation — How to get meaningful backtraces in Gentoo]
+
* [http://fedoraproject.org/wiki/StackTraces Fedora - StackTraces]
 +
* [https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces/Details#obtain-a-stacktrace GNOME - Getting Stack Traces]
 +
* [http://linux.bytesex.org/gdb.html gdb mini intro]

Latest revision as of 07:48, 25 May 2016

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

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements.Tango-edit-clear.png

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

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 debug symbols from executables. To apply this setting to a single package, modify the PKGBUILD:

options=(debug !strip)

Alternatively you can put the debug information in a separate package by enabling both debug and strip, debugging information will then be stripped from the main package and placed in a separate foo-debug package.

It is possible to have a separate config for your debug builds that will load the default config and alter some variables. This way you can create debug builds only when you need to and without editing PKGBUILD or configuration files each time.

. /etc/makepkg.conf

cmake() {
  command cmake -DCMAKE_BUILD_TYPE=Debug "$@"
}

_remove_opt() {
local newarr=()
for el in "${OPTIONS[@]}"; do
case $el in
"$1") ;;
*) newarr+=( "$el" );;
esac
done
OPTIONS=( "${newarr[@]}" )
}

_remove_opt strip
_remove_opt !strip
_remove_opt debug 
_remove_opt !debug
OPTIONS=( "${OPTIONS[@]}" !strip debug )

Save it into /etc/makepkg-debug.conf and use the it like this:

 makepkg --config /etc/makepkg-debug.conf ...


Note: It is insufficient to simply install the newly compiled debug package, because the debugger will check that the file containing the debug symbols is from the same build as the associated library and executable. You must install both of the recompiled packages. In Arch, the debug symbols files are installed under /usr/lib/debug. See the GDB documentation for more information about debug packages.

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.

Qt4

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.

Qt5

The qt-debug repository contains pre-built Qt/PyQt packages with debug symbols. See also upstream instructions.

CMAKE (KDE) applications

KDE and related programs typically use cmake. To enable debug information and disable optimisations, change -DCMAKE_BUILD_TYPE to Debug. To enable debug information while keeping optimisations enabled, change -DCMAKE_BUILD_TYPE to RelWithDebInfo.

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

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Mention core dumps (Discuss in Talk:Debug - Getting Traces#)

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