Proporcionando una Traza de la Pila (Stack Trace)
Esta página ha sido tomada de la documentación anterior de Fedora Wiki. Se ha limpiado para publicarla aquí en el Portal Fedora Docs, pero todavía no se ha revisado su precisión técnica. Es probablemente
Se agradecen mucho las revisiones de precisión técnica. Si desea ayudar, consulte el archivo README en el repositorio fuente para obtener instrucciones. Solicitudes de extracción aceptadas en https://pagure.io/fedora-docs/quick-docs Una vez haya corregido esta página, borre este anuncio. |
Una traza de pila (stack trace) es uno de los recursos más importantes que puede proporcionar para ayudar a otros a depurar el fallo de una aplicación. Esta página detalla la importancia de las trazas de pila y describe varios métodos para obtenerlas.
Si experimenta un fallo, los pasos básicos para generar una traza de pila útil para aplicaciones estándar del entorno de escritorio Gnome son:
-
Instale los paquetes RPM -debuginfo apropiados antes del fallo (consulte la sección "¿Qué son los RPM de información de depuración y cómo los obtengo?" a continuación).
-
Espere a que se produzca el fallo o realice los pasos necesarios para reproducirlo.
-
En Fedora, ABRT (Automatic Bug Reporting Tool o Herramienta de Informe Automático de Errores en español) detectará automáticamente el fallo y obtendrá la traza de pila.
-
Incluya la traza de pila en su informe de error (consulte el documento "Cómo Presentar un Error" para obtener instrucciones completas).
Si ABRT no se inicia automáticamente, deberá iniciar el programa de un modo especial, utilizando un depurador (como gdb). Vea la sección Obtener una traza de pila utilizando solo GDB a continuación.
Se aplican instrucciones especiales para programas Java y Firefox.
¿Qué es una traza de pila?
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.
¿Qué aspecto tiene una traza de pila?
Una traza de pila típica es parecida a lo siguiente:
[New Thread 8192 (LWP 15167)]
0x420ae169 in wait4 () from /lib/i686/libc.so.6
.
.
.
Una mejor traza de pila, con símbolos de información de depuración (ver más abajo) se ve así:
0x000000350a6c577f in *__GI___poll (fds=0xe27460, nfds=9, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:83
83 return INLINE_SYSCALL (poll, 3, CHECK_N (fds, nfds), nfds, timeout);
.
.
.
Observe que aparecen los nombres de archivos y los números de línea donde se llaman las funciones.
¿Qué son los símbolos de depuración y por qué son importantes?
Cuando un programa se compila con modificaciones especiales para generar símbolos de depuración (el modificador -g del compilador), 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.
¿Qué son los RPM de información de depuración y cómo los obtengo?
Fedora incluye un tipo especial de RPM llamados RPMs de información de depuración (debuginfo). Estos RPM creados automáticamente que 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
[warren@computer ~] $ rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' gaim gaim-debuginfo
gaim-2.0.0-0.26.beta5.i386
gaim-debuginfo-2.0.0-0.26.beta5.i386
Cada paquete que contenga binarios en su distribución tiene un paquete debuginfo correspondiente.
Instalando RPMs debuginfo usando DNF.
debuginfo-install es un útil complemento, perteneciente al paquete dnf-plugins-core
, que habilita automáticamente los repositorios de debuginfo y descarga todos los paquetes de debuginfo necesarios . Usted puede hacer:
$ dnf debuginfo-install <pkg-spec>
para instalar todos los paquetes debuginfo necesarios para el paquete <pkg-spec>
.
Para instalar únicamente el conjunto mínimo de paquetes debuginfo, use la lista de paquetes del comando (sin instalar nada) para obtener los nombres de los paquetes debuginfo y sus respectivos repositorios. Luego, construya el comando de instalación de acuerdo con el siguiente ejemplo:
$ dnf --enablerepo=fedora-debuginfo --enablerepo=updates-debuginfo install <pkg-spec>-debuginfo
Esto es útil cuando no desea instalar paquetes debuginfo para todas las dependencias del paquete a depurar, ya que a menudo no se requieren.
Instalando RPMs debuginfo usando yum.
El comando debuginfo-install
es una herramienta útil, perteneciente al paquete yum-utils
, que habilita automáticamente los repositorios de debuginfo y descarga los paquetes debuginfo necesarios. Usted puede hacer:
$ debuginfo-install foo
para instalar todos los paquetes debuginfo necesarios para el paquete foo
.
Para instalar únicamente el conjunto mínimo de paquetes debuginfo, use la salida de debuginfo-install
(sin instalar nada) para obtener los nombres de los paquetes debuginfo y sus respectivos repositorios. Luego, construya el comando de instalación de acuerdo con el siguiente ejemplo:
$ yum --enablerepo fedora-debuginfo,updates-debuginfo install foo-debuginfo
Esto es útil cuando no desea instalar paquetes debuginfo para todas las dependencias del paquete a depurar, ya que a menudo no se requieren.
Instalando RPMs debuginfo manualmente.
Estos paquetes pueden descargarse desde los espejos normales de Fedora en el subdirectorio "debug" del directorio de la arquitectura. Por ejemplo, los paquetes debuginfo para la última versión de desarrollo están disponibles en http://mirrors.fedoraproject.org/publiclist/Fedora/development/ . Utilice el espejo más cercano a usted para realizar la descarga.
Empaquetadores.
Si usted es un empaquetador buscando información acerca de los RPMs debuginfo, consulte el documento Debuginfo packages.
¿Cómo genero un traza?
Primero compruebe que tiene instalados los paquetes debuginfo para la aplicación que está depurando y todas las librerías relacionadas. Un desarrollador a menudo le dice que instale paquetes debuginfo específicos porque puede saber a través de un traza de la pila que librerías están involucradas en la caída. Vea abajo paquetes recomendados para algunos tipos comunes de aplicaciones.
Hay diversas maneras de obtener un traza de la pila:
-
Obtener una traza de la pila utilizando Obtener una traza de la pila usando solo GDB Obtener una traza de pila utilizando solo GDB.
-
Obtener una traza de la pila desde un volcado del núcleo con GDB. core dump with GDB.
-
Obtener una traza de la pila desde una aplicación usando la Herramienta de Informe Automático de Errores. Automatic Bug Reporting Tool.
¿Qué paquetes debuginfo debería instalar?
Como mínimo usted necesitará instalar el paquete debuginfo para la aplicación que está cayendo. Puede averiguar en que paquete se encuentra esta aplicación tecleando rpm -qf path-of-program
.
Para ciertos tipos de programas es también muy útil instalar un par de paquetes predeterminados que son útiles para casi todas las trazas de la pila:
-
Aplicaciones Gnome y aplicaciones que utilizan Gtk+:
glib2-debuginfo, pango-debuginfo, gtk2-debuginfo
-
Aplicaciones KDE:
qt-debuginfo, kdelibs-debuginfo
Obtener una traza de pila utilizando solo GDB
Si usted está ejecutando un programa Java como Eclipse o Tomcat, la situación es un poco más complicada – vea detalles en programas Java Programas Java. |
Primero, ejecute el siguiente comando para iniciar gdb:
gdb name-of-program
Donde name-of-program es el nombre del programa que ha caído (por ejemplo: /usr/bin/gnome-panel
).
Después, en el símbolo de gdb, teclee:
run
Si usted necesita darle cualquier argumento al programa, déselos después del comando run, como:
run --argument
Una vez que el programa está corriendo, reproduzca la caída y vuelva al terminal donde está ejecutando gdb. El símbolo de gdb debería estar mostrando – si no, pulse Control+C para entrar en el depurador. En el símbolo del depurador gdb, teclee:
thread apply all bt full
Si esto no funciona (lo que significa que no obtiene ningún resultado—este puede ser el caso en programas que no son multiproceso), teclee en su lugar <code>bt</code>. Si aún no tiene ninguna salida, lea [[#special| esta nota]] sobre la obtención de una traza de pila bajo circunstancias especiales. La salida es la traza de pila. Corte y pegue todo en un archivo de texto.
Usted puede salir de gdb tecleando quit
.
Algunas veces, la traza puede ser muy larga y dificultar el copia y pega. En dichas situaciones, es conveniente guardar la traza en un archivo:
gdb
> run
# program crashes
> set logging file backtrace.log
> set logging on
> thread apply all bt full
> set logging off
> quit
Obtener una traza de pila desde un volcado de núcleo
Si el programa que falla deja un volcado de núcleo, usted puede usar GDB para obtener una traza de pila. Los volcados de núcleo se guardan en un archivo en su disco duro y generalmente reciben un nombre similar a "core" o "core.3124". Para obtener una traza de pila de uno de estos archivos, ejecute el siguiente comando:
gdb name-of-program core-file-name
Donde name-of-program
es el nombre del programa que ha fallado (por ejemplo: /usr/bin/gnome-panel) y core-file-name
es el nombre del archivo core que contiene el volcado de núcleo (por ejemplo: core.7812).
Después, en el símbolo de gdb, teclee:
thread apply all bt full
Si esto no funciona (lo que significa que no obtiene ningún resultado—esto puede ser el caso en programas que no son multiproceso), teclee en su lugar bt
. Si aún no tiene ninguna salida, lea esta nota sobre la obtención de una traza de pila bajo circunstancias especiales. La salida es la traza de pila. Corte y pegue todo en un archivo de texto.
Usted puede salir de gdb tecleando quit
.
Tenga en cuenta que la creación de archivos core está deshabilitada en Fedora de forma predeterminada (en /etc/profile). Para habilitarlo para una sesión de shell, teclee en el indicador de shell:
ulimit -c unlimited
Como instalar ABRT
Si usted instaló Fedora por medio de una imagen LiveCD image, ABRT debería estar ya instalado. Usted debería ser capaz de iniciarlo en Aplicaciones → Herramientas del Sistema → Automatic Bug Reporting Tool. Si ABRT no está instalado, por cualquier razón, usted puede instalarlo manualmente haciendo lo siguiente en una línea de comandos:
$ su -c 'dnf install abrt'
o ir a Sistema
→ Administración
→ Añadir/Quitar Software
en Gnome y teclear abrt
en la caja de búsqueda y seleccionar Buscar
. Seleccione el paquete abrt y aplique los cambios.
Configurar ABRT para Bugzilla
Vaya a Aplicación
→ Herramientas del Sistema
→ ABRT
y selecciónelo para arrancarlo manualmente. Una vez que aparece la ventana GUI, elija Editar
→ Complementos
y de la ventana Ajustes, desplace hacia abajo, resalte Bugzilla y elija Configurar Complemento
. La URL de Bugzilla debería ser https://bugzilla.redhat.com e introduzca su clave y contraseña de acceso a Bugzilla en las cajas apropiadas.
Si no tiene una cuenta Bugzilla todavía, ahora es el momento de obtener una, solo vaya a la URL que se muestra en esa página y cree una nueva cuenta. |
La próxima vez que tenga un programa que falla y dispare ABRT, cuando usted pulse Informar, ABRT será capaz de acceder automáticamente a Bugzilla y enviar el Informe de Error por usted.
Usar ABRT
(Lo siguiente asume que tiene Gnome como escritorio … tendrá que actualizar algo más para KDE/Otros)
Si ABRT detecta un programa que falle, usted tendrá una alerta ABRT. Esto será indicado visualmente por una luz roja parpadeante en la bandeja del sistema. Pulse con el botón izquierdo en la luz de alerta y debería arrancar la Automatic Bug Reporting Tool (Herramienta Automática de Informe de Error), mostrando todas las caídas registradas. Para informar del error, pulse con el botón derecho y elija informar. ABRT obtendrá los registros que necesita enviar con el error y luego le informará que enviará el error en su nombre. Si usted tiene configurado ABRT como en la sección anterior, le pedirá que verifique sin quiere incluir o no los diversos registros, después irá automáticamente a Bugzilla y abre el error, agregando los registros al error. Después le mostrará el número de error para que usted pueda hacer un seguimiento de lo que se está trabajando.
Configurar ABRT cuando falta Información de Depuración
Cuando usted pulsa con el botón derecho en ABRT y elige Informar, ABRT intentará salir y recuperar los registros que deberá enviar como parte del informe de error. Los desarrolladores han añadido código para detectar si se incluyen o no trazas simbólicas dentro de la traza inversa y si detecta que no hay ninguna, ABRT le alertará de esto y le mostrará el comando que debe ejecutar. Esto es lo mismo que se muestra en la sección debuginfo.
Programas corriendo como otro usuario
Si usted no obtiene ninguna salida de gdb después de teclear thread apply all bt
o` bt`, puede ser porque el programa está corriendo como root o como otro usuario. En GNOME, por ejemplo, este es el caso cuando ejecuta gnome-games. En tales casos, usted necesitará ser root con el objetivo de obtener una traza. Así, salga de gdb, acceda como root y repita los pasos para obtener una traza de pila.
Firefox
-
Instale los paquetes de información de depuración Firefox y Xulrunner – ejecute
ebuginfo-install firefox xulrunner
como root en la línea de comando. -
Ejecute
firefox -g
en la línea de comando. Esto arrancará firefox corriendo dentro del depurador gdb. -
En gdb, usted debería ver el símbolo de gdb
(gdb)
. Envíe el comandorun -safe-mode
. Se desplegará una ventana de diálogo, deshabilite todos los complementos aquí y continúe en modo seguro. -
Haga lo que sea necesario para hacer que firefox caíga y siga las instrucciones de arriba sobre la utilización de gdb.
-
Cuando Firefox caiga obtenga la traza y agréguela a bugzilla.
Para información adicional vea Directrices de depuración para productos Mozilla.
Thunderbird
Es casi lo mismo que para Firefox, solo que los paquetes de información de depuración son diferentes. Instálelos como root con el comando "debuginfo-install thunderbird" en la consola.
Para información adicional vea Directrices de depuración para productos Mozilla.
Programas Java
Vea el documento Resolución de Problemas en Programas Java para información sobre como obtener trazas de la pila desde programas corriendo en Java.
Demonios y sus engendros
Deberá recopilar el seguimiento del archivo principal.
Asegúrese de que el script de inicio de su demonio no prohíba volcar archivos principales al disco. Añada la línea DAEMON_COREFILE_LIMIT=unlimited
a su archivo de configuración en /etc/sysconfig
. Por ejemplo, el demonio Bluetooth (hcid) utiliza /etc/sysconfig/bluetooth
.
Después configure el kernel de modo que el volcado del principal se escriba en una ubicación conocida como /tmp
. Como root, ejecute:
echo /tmp/core > /proc/sys/kernel/core_pattern
Para hacer este cambio permanente, añada esta línea a /etc/sysctl.conf:
kernel.core_pattern = /tmp/core
Y ejecute sysctl -p
para aplicarlo de inmediato.
Una lista completa de posibles patrones para el archivo principal está disponible en la Documentación del kernel sysctl/kernel.txt.
Finalmente, después de reproducir su problema, puede verificar que binario creó el archivo principal con file /tmp/core.1234
. Luego ejecute gdb en el archivo para crear una traza de pila post-mortem:
gdb /path/to/binary/file /tmp/core.1234
y siga las instrucciones anteriores para el uso de gdb.
Usted puede probar si el volcado de un archivo principal trabajaría ejecutando |
Otras herramientas
Valgrind
The brilliant tool valgrind is often able to say more about what is going wrong; it can give a strack trace to the point where things start to go wrong, which might be long time before the program actually crashes. Programs run through valgrind will run an order of magnitude slower and use more memory, but it will be buddyamazingly usable.
With valgrind installed (`dnf install valgrind) you can use it on a program:
valgrind name-of-program program-arguments
With debuginfo installed stacktraces will use symbolic names. See [http://valgrind.org/ valgrind.org] for more info and tips and tricks.
strace
strace can track all system calls made by a program, which can also be helpful in debugging, though it cannot produce stack traces. Install with dnf install strace
, and see man strace
for details.
The situation is a bit improved. Now stack trace feature is implemented (strace -k
). Though it is disabled when building because the implementation is not stable on i386.
References
-
Much of the text from this page comes from the excellent GNOME bugsquad on getting stack traces.
Want to help? Learn how to contribute to Fedora Docs ›