En mi aplicación, manejo SIGSEG para generar una traza inversa y llamo al abort() para generar un volcado del núcleo.¿Cómo encontrar qué hilo causó a SEGFAULT en una sesión post-mortem gdb?
Si ahora ejecuto un análisis gdb-post-mortem del núcleo, el hilo que causó el SEGFAULT ya no es visible. ¿Hay algo que pueda hacer para ver la causa de SEGFAULT?
Saludos cordiales, Martin
puede utilizar el comando thread apply all bt o thread apply all bt full para obtener trazas de todas las discusiones. Podría ser útil.
Por cierto, si se deshace de su controlador, ¿su sistema operativo creará un archivo central?
Actualmente utilizo el controlador para escribir una traza inversa a stderr, así que tengo algo, ya que no pude obtener nada del archivo central. Tengo que probar si el controlador predeterminado generará "mejores" volcados de núcleo. –
'ulimit -c unlimited' y verá qué núcleo obtendrá sin ningún controlador. –
@skwllsp, ¿hay alguna manera de saber exactamente qué hilo causó el SIGSEGV? ¿Quiso decir que en realidad no es posible conocerlo y que se deben usar las trazas inversas para encontrarlo? – russoue
¿También está haciendo otro trabajo en el controlador? ¿Por qué no dejar que el sistema operativo use su comportamiento predeterminado para dejar un núcleo para usted? –
Simplemente creando un retraso en stderr y luego llamando a abort(). –
Por favor, especifique su sistema operativo y qué es exactamente lo que observa en GDB. En Linux (y en cualquier otro UNIX que se me ocurra) el controlador SIGSEGV se ejecutará en el hilo que causó SIGSEGV en primer lugar. Si ese manejador llama a abort(), entonces el volcado del núcleo contendrá ese hilo como el hilo # 1, y no habrá problemas para encontrar exactamente qué instrucción y qué pila de llamadas causó el problema. Como tiene dificultades, tiene un sistema operativo "extraño" o no está describiendo correctamente lo que realmente observa. –