Análisis coredump post-mortem remoto sin tener símbolos de depuración exactos para bibliotecas de sistema compartido

Question

¿Cómo se suele solucionar este problema? Imagine que un hilo se cuelga dentro del código libc (que es una biblioteca compartida del sistema) en Computer1 y luego genera un coredump. Pero el Computer2 en el que se analizará este núcleo puede tener una versión diferente de libc.

Así:

1. Qué importante es tener la misma biblioteca compartida en el equipo remoto? ¿El gdb reconstruirá correctamente stacktrace sin tener la misma versión exacta de libc en Conputer2?

2. ¿Qué tan importante es tener símbolos de depuración correctos para libc? ¿El gdb reconstruirá correctamente stacktrace sin tener exactamente los mismos símbolos de depuración en Computer2?

3. ¿Y cuál es la forma "correcta" de evitar este problema de errores de depuración de las bibliotecas del sistema compartido? Para mí, parece que no hay una única solución que resuelva este problema de una manera elegante. Quizás alguien pueda compartir su experiencia?

Answer 1

1. Depende. En algunos procesadores, como x86_64, se requieren los valores correctos unwind descriptors para que GDB desenrolle correctamente la pila. En una máquina de este tipo, es probable que el análisis de la pila secundaria con la libc no coincidente produzca una basura completa.

2. No necesita símbolos de depuración para que libc obtenga el seguimiento de la pila. No obtendrás números de archivo y línea sin símbolos de depuración, pero deberías obtener los nombres correctos de las funciones (excepto cuando ha tenido lugar la alineación).

3. La premisa de su pregunta es incorrecta: los símbolos de depuración no tienen nada que ver con esto. La forma "correcta" para analizar coredump en C2, cuando que coredump fue producido en C1, es tener una copia de bibliotecas de C1 (en, por ejemplo /tmp/C1/lib/...) y directa GDB utilizar esa copia en vez de de la C2 instalado libc con

   (gdb) set solib-absolute-prefix /tmp/C1

comando.

Nota: configuración anterior imprescindible estar en vigor antes de cargar el núcleo en el BGF. Esto:

gdb exe core 
(gdb) set solib-absolute-prefix /tmp/C1 

no funciona (el núcleo se lee antes de que la configuración entre en vigor).

Aquí es la forma correcta:

gdb exe 
(gdb) set solib-absolute-prefix /tmp/C1 
(gdb) core core 

(He tratado de encontrar una referencia a esto en la web, pero no lo hice).

¿Qué son descriptores de desenrollado?

Se requieren descripciones de desenrollar cuando el código se compila sin punteros de marco (por defecto para x86_64 en modo optimizado).Tal código hace no save% rbp register, por lo que GDB necesita que se le diga cómo "retroceder" desde el fotograma actual al fotograma que llama (este proceso también se conoce como desenrollar la pila).

¿Por qué no se incluye libc.so de C1 en el núcleo?

El archivo de núcleo por lo general contiene solo los contenidos de los segmentos de escritura del espacio de direcciones del programa. Los segmentos de solo lectura (donde residen el código ejecutable y los descriptores de desenrollado) no suelen ser necesarios; puede leerlos directamente desde libc.so en el disco.

¡Excepto que esto no funciona cuando se analiza el núcleo de C1 en C2!

Algunos (pero no todos) los sistemas operativos permiten configurar "coredumps completos", donde el sistema operativo también eliminará las asignaciones de solo lectura, para que pueda analizar el núcleo en cualquier máquina.