Providing a Stack Trace

Una traza de pila es una lista de las llamadas a funciones que conducen a algún punto del programa. Herramientas de depuración como gdb o bug-buddy pueden obtener trazas de pila de aplicaciones fallidas para que los desarrolladores puedan descubrir qué salió mal.

Una traza de pila típica es parecida a lo siguiente:

Una mejor traza de pila, con símbolos de información de depuración (ver más abajo) se ve así:

Observe que aparecen los nombres de archivos y los números de línea donde se llaman las funciones.

Cuando un programa se compila con modificaciones especiales para generar símbolos de depuración (el modificador -g del compilador), se almacena información adicional en el archivo del programa. Esta información puede ser utilizada para generar una traza de pila que contenga mucha más información, como el número de línea exacto del archivo fuente donde algo salió mal. Sin esta información, es muy difícil determinar qué salió mal observando la traza de pila.

Fedora incluye un tipo especial de RPM llamados RPMs de información de depuración (debuginfo). Estos RPM creados automáticamente contienen la información de depuración de los archivos del programa pero almacenados en un archivo externo. Todas las herramientas que manejan información de depuración saben cómo buscar automáticamente en estos archivos. Esto le permite instalar fácilmente información de depuración cuando la necesite. Debe instalar la versión y arquitectura exactas de debuginfo correspondientes a la aplicación que está intentando depurar.

Ejemplo: Verificando Versión y Arquitectura Coincidentes

Cada paquete que contenga binarios en su distribución tiene un paquete debuginfo correspondiente.

First make sure that you have installed the debuginfo packages for the application you are debugging and all related libraries. A developer often tells you to install specific debuginfo packages because he can tell from a stack trace which libraries are involved in the crash. See below for recommended packages for some common type of applications.

There are several ways to get a stack trace:

At the very least you will need to install the debuginfo package for the application that is crashing. You can find out what package this application is in by typing rpm -qf path-of-program.

For certain types of programs it is also very useful to install a couple of default packages that are useful for almost all stack traces:

First, run the following command to start gdb:

Where name-of-program is the name of the program that crashed (for example: /usr/bin/gnome-panel).

Then, at the gdb prompt, type:

If you need to give any arguments to the program, give them after the run command, like:

Once the program is running, reproduce the crash and go back to the terminal where you ran gdb. The gdb prompt should be shown - if not, hit Control+C to break into the debugger. At the gdb debugger prompt, type:

If that does not work (meaning that you don’t get any output—​this may be the case in programs which are not multi-threaded), type <code>bt</code> instead. If you still do not have any output, read [[#special| this note]] about obtaining a stack trace under special circumstances. The output is the stack trace. Cut and paste all of it into a text file.

You can quit gdb by typing quit.

Sometimes, the trace can be quite large and it is difficult to copy and paste it. In such situations, storing the trace to a file is convenient:

If the program that crashes leaves a core dump, you can use GDB to obtain a stack trace. Core dumps are saved in a file on your hard disk and are usually named something along the lines of "core" or "core.3124". To obtain a stack trace from one of these files, run the following command:

Where name-of-program is the name of the program that crashed (for example: /usr/bin/gnome-panel), and core-file-name is the name of the core file that contains the core dump (for example: core.7812).

Then, at the gdb prompt, type:

If that does not work (meaning that you don’t get any output—​this may be the case in programs which are not multi-threaded), type bt instead. If you still do not have any output, read this note about obtaining a stack trace under special circumstances. The output is the stack trace. Cut and paste all of it into a text file.

You can quit gdb by typing quit.

Note that creation of core files is disabled in Fedora by default (in /etc/profile). To enable them for a shell session, type at the shell prompt:

If you installed Fedora via a LiveCD image, ABRT should already be installed. You should be able to start it in Applications → System Tools → Automatic Bug Reporting Tool. If ABRT is not installed, for whatever reason, you can install it manually by doing the following on a command line:

or go to System → Administration → Add/Remove Software in Gnome, and type`abrt` in the search box and select Find. Select the abrt package and apply the changes.

Go to Application → System Tools → Automated Bug Reporting Tool and select it to start it manually. Once the GUI window appears, choose Edit → Plugins and from the Settings window, scroll down, highlight Bugzilla and choose Configure Plugin. The Bugzilla URL should be https://bugzilla.redhat.com and enter your own Bugzilla login and password in the proper boxes.

Next time you have a program crash, and ABRT triggers, when you hit Report, ABRT will be able to automatically log in to Bugzilla and submit a Bug Report for you.

(The following assumes Gnome as the desktop …​ someone else will have to update for KDE/Others)

If ABRT detects a crashed program, you will get an ABRT alert. This will be visually indicated by a flashing red light in the system tray. Left click on the alert light, and the Automatic Bug Reporting Tool should start, displaying all of the crashes it has registered. To report the bug, right click on it and choose report. ABRT will gather the logs it needs to submit with the bug and will then let you know it is going to submit a bug on your behalf. If you have configured ABRT as in the previous section, it will then ask you to verify whether or not to include the various logs, then will automatically go out to Bugzilla and open a bug, attaching the logs into the bug. It will then show you the bug number so that you can track the bug as it is worked on.

When you right click on a bug in ABRT and choose Report, ABRT will attempt to go out and retrieve the logs it will need to send as part of the bug report. The developers have added code to detect whether or not symbolic traces are included within the backtrace, and if it detects that there are none, ABRT will alert you of this, and will show you the command to run. This is the same as what is shown in the debuginfo section.

If you do not get any output from gdb after typing thread apply all bt or bt, it may be because the program is run as root or as another user. In GNOME for example, this is the case when running gnome-games. In such cases, you will need to be root in order to capture a trace. So, quit gdb, login as root, and then repeat the steps to obtain a stack trace.