Obteniendo una mejor depuración cuando Linux falla en un programa en C

Question

Tenemos una versión integrada del kernel de Linux ejecutándose en un núcleo de MIP. El programa que hemos escrito ejecuta un conjunto de pruebas particular. Durante una de las pruebas de estrés (se ejecuta durante aproximadamente 12 horas) obtenemos un fallo seg. Esto a su vez genera un volcado de núcleo.

Desafortunadamente, el volcado del núcleo no es muy útil. El bloqueo está en alguna biblioteca del sistema que está vinculada dinámicamente (probablemente pthread o glibc). La traza en el volcado de memoria no es muy útil, ya que sólo muestra el punto de choque y no hay otras personas que llaman (nuestra aplicación de espacio de usuario se construye con -O0 -g, pero todavía no hay información sobre el rastreo hacia atrás):

Cannot access memory at address 0x2aab1004 
(gdb) bt 
#0 0x2ab05d18 in ??() 
warning: GDB can't find the start of the function at 0x2ab05d18. 

    GDB is unable to find the start of the function at 0x2ab05d18 
and thus can't determine the size of that function's stack frame. 
This means that GDB may be unable to access that stack frame, or 
the frames below it. 
    This problem is most likely caused by an invalid program counter or 
stack pointer. 
    However, if you think GDB should simply search farther back 
from 0x2ab05d18 for code which looks like the beginning of a 
function, you can increase the range of the search using the `set 
heuristic-fence-post' command. 

Otro desafortunado -ity es que no podemos ejecutar gdb/gdbserver. gdb/gdbserver sigue rompiendo __nptl_create_event. Al ver que la prueba crea subprocesos, temporizadores y destruye, cada 5 segundos es casi imposible sentarse durante mucho tiempo y continuar golpeándolos.

EDIT: Otra nota, backtrace y backtrace_symbols no son compatibles con nuestra cadena de herramientas.

Por lo tanto:

1. ¿Hay una manera de atrapar culpa seg y generar más datos backtrace, punteros de pila, pila de llamadas, etc.?

2. ¿Hay alguna manera de obtener más datos de un volcado del núcleo que se colgó en un archivo .so?

Thanks.

Answer 1

Si todo lo demás falla, ejecute el comando utilizando el depurador.

Simplemente ponga "gdb" en la forma de su comando de inicio normal e ingrese "c" para continuar el proceso. Cuando la tarea se segmenta por separado, volverá al prompt de gdb interactivo en lugar de al volcado del núcleo. Debería poder obtener trazas de pila más significativas, etc.

Otra opción es usar "truss" si está disponible. Esto le indicará qué llamadas del sistema se estaban utilizando en el momento de la terminación anómala.

Answer 2

BGF no puede encontrar el inicio de la función en 0x2ab05d18

Lo que está en esa dirección en el momento del accidente?

Haga info shared, y descubra si hay una biblioteca que contenga esa dirección.

La causa más probable de sus problemas: ¿ejecutó strip libpthread.so.0 antes de subirlo a su destino? No hagas eso: GDB requiere libpthread.so.0 a no ser eliminado. Si su cadena de herramientas contiene libpthread.so.0 con símbolos de depuración (y por lo tanto demasiado grande para el destino), ejecute strip -g en él, no un strip completo.

Actualización:

info shared producido No se puede acceder a la memoria en la dirección 0x2ab05d18

Esto significa que el BGF no puede acceder a la lista de la biblioteca compartida (que luego explicar el seguimiento de la pila que falta). La causa más común: el binario que realmente produjo el core no coincide con el binario que le diste a GDB. Una causa menos común: el volcado del núcleo se truncó (quizás debido a que el valor ulimit -c se estableció demasiado bajo).