Difference between revisions of "Debug - Getting Traces"

From ArchWiki
Jump to: navigation, search
(http -> https://aur.archlinux.org)
m (minor improvements)
Line 2: Line 2:
 
{{i18n|Debug - Getting Traces}}
 
{{i18n|Debug - Getting Traces}}
  
This article will try to give you an idea how to create Arch package. This provides debug and traces information for reporting software bugs (for example after use of [http://www.archlinux.org/packages/search/?q=bug-buddy Bug-Buddy]).
+
This article will try to give you an idea how to create Arch package, which provides debug and traces information for reporting software bugs.
  
 
==Discovering name of package(s)==
 
==Discovering name of package(s)==
Line 122: Line 122:
  
 
==Conclusion==
 
==Conclusion==
Use the completed stack trace to inform developers of the 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 ==

Revision as of 08:48, 2 April 2012

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

This article will try to give you an idea how to create Arch package, which provides debug and traces information for reporting software bugs.

Discovering name of package(s)

A few facts of debug messages

When looking at debug message, such as (stripped):

...
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
...

you can see ?? at the place where debugging info is missing and also the name of library or executable which called the function. Similarly, when the line (no debugging symbols found) appears in a message, it means that you have to look for a file whose name is stated.

Finding package

Use Pacman to retrieve name of package:

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

We have found that package is called 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.

Obtaining 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:

  1. AUR or
  2. ABS

Using AUR

Use 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 Tarball. Store it in location of your choice. Use tar to extract it and change directory:

$ tar xvzf name_of_tarball.tar.gz
$ cd name_of_tarball

Using ABS

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
$ cd core/glibc
$ makepkg -s

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.

Global settings

Modify makepkg's configuration file /etc/makepkg.conf to contain following lines:

CFLAGS="-g -march=i686 -O1 -pipe"
CXXFLAGS="-g -march=i686 -O1 -pipe"

and

OPTIONS=(!strip !docs libtool emptydirs)

These settings (in bold) will force compilation with debugging information and will disable stripping of executable.

One package settings only

Modify foo's PKGBUILD file to contain the following lines:

options=(!strip)

Into the build() function, add following lines at the very beginning:

export CFLAGS="$CFLAGS -g -O1"
export CXXFLAGS="$CXXFLAGS -g -O1"
Note: A change in optimization level below -O1 cannot be generally recommended as 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.

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

The actual backtrace resp. 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 it is already 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) bt

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>

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