10.3. Inspección de los estados de caída de la aplicación con los volcados del núcleo

Procedimiento

1. Para identificar el archivo ejecutable en el que se produjo el fallo, ejecute el comando eu-unstrip con el archivo de volcado del núcleo:

   $ eu-unstrip -n --core=./core.9814
   0x400000+0x207000 2818b2009547f780a5639c904cded443e564973e@0x400284 /usr/bin/sleep /usr/lib/debug/bin/sleep.debug [exe]
   0x7fff26fff000+0x1000 1e2a683b7d877576970e4275d41a6aaec280795e@0x7fff26fff340 . - linux-vdso.so.1
   0x35e7e00000+0x3b6000 374add1ead31ccb449779bc7ee7877de3377e5ad@0x35e7e00280 /usr/lib64/libc-2.14.90.so /usr/lib/debug/lib64/libc-2.14.90.so.debug libc.so.6
   0x35e7a00000+0x224000 3ed9e61c2b7e707ce244816335776afa2ad0307d@0x35e7a001d8 /usr/lib64/ld-2.14.90.so /usr/lib/debug/lib64/ld-2.14.90.so.debug ld-linux-x86-64.so.2

   La salida contiene detalles para cada módulo en una línea, separados por espacios. La información aparece en este orden:

   1. La dirección de memoria a la que se asignó el módulo
   2. El build-id del módulo y en qué lugar de la memoria se encuentra
   3. El nombre del archivo ejecutable del módulo, mostrado como - cuando es desconocido, o como . cuando el módulo no ha sido cargado desde un archivo
   4. La fuente de información de depuración, mostrada como un nombre de archivo cuando está disponible, como . cuando está contenida en el propio archivo ejecutable, o como - cuando no está presente en absoluto
   5. El nombre de la biblioteca compartida (soname) o [exe] para el módulo principal

   En este ejemplo, los detalles importantes son el nombre del archivo /usr/bin/sleep y el build-id 2818b2009547f780a5639c904cded443e564973e en la línea que contiene el texto [exe]. Con esta información, puedes identificar el archivo ejecutable necesario para analizar el volcado del núcleo.

2. Obtenga el archivo ejecutable que se estrelló.

   • Si es posible, cópielo del sistema en el que se produjo el fallo. Utilice el nombre del archivo extraído del archivo del núcleo.

   • También puede utilizar un archivo ejecutable idéntico en su sistema. Cada archivo ejecutable construido en Red Hat Enterprise Linux contiene una nota con un valor único de build-id. Determine el build-id de los archivos ejecutables relevantes disponibles localmente:

     $ eu-readelf -n executable_file

     Utilice esta información para hacer coincidir el archivo ejecutable del sistema remoto con su copia local. El build-id del archivo local y el build-id que aparece en el volcado del núcleo deben coincidir.

   • Por último, si la aplicación se instala desde un paquete RPM, puede obtener el archivo ejecutable del paquete. Utilice la salida de sosreport para encontrar la versión exacta del paquete requerido.
3. Obtenga las bibliotecas compartidas utilizadas por el archivo ejecutable. Utilice los mismos pasos que para el archivo ejecutable.
4. Si la aplicación se distribuye como un paquete, cargue el archivo ejecutable en GDB, para mostrar pistas sobre los paquetes de depuración que faltan. Para más detalles, consulte Sección 7.4, “Obtención de paquetes debuginfo para una aplicación o librería usando GDB”.

5. Para examinar el archivo del núcleo en detalle, cargue el archivo ejecutable y el archivo de volcado del núcleo con GDB:

   $ gdb -e executable_file -c core_file

   Otros mensajes sobre los archivos que faltan y la información de depuración le ayudan a identificar lo que falta para la sesión de depuración. Vuelva al paso anterior si es necesario.

   Si la información de depuración de la aplicación está disponible como un archivo en lugar de como un paquete, cargue este archivo en GDB con el comando symbol-file:

   (gdb) archivo-símbolo program.debug

   Sustituya program.debug por el nombre real del archivo.

   Nota

   Puede que no sea necesario instalar la información de depuración para todos los archivos ejecutables contenidos en el volcado del núcleo. La mayoría de estos archivos ejecutables son bibliotecas utilizadas por el código de la aplicación. Es posible que estas bibliotecas no contribuyan directamente al problema que se está analizando, y no es necesario incluir información de depuración para ellas.

6. Utilice los comandos GDB para inspeccionar el estado de la aplicación en el momento en que se estrelló. Ver Capítulo 8, Inspección del estado interno de la aplicación con GDB.

   Nota

   Cuando se analiza un archivo de núcleo, GDB no se adjunta a un proceso en ejecución. Los comandos para controlar la ejecución no tienen efecto.