Miglioramento del debug in caso di arresto anomalo di Linux in un programma C

Question

Abbiamo una versione integrata del kernel Linux in esecuzione su un core MIP. Il programma che abbiamo scritto gestisce una particolare suite di test. Durante uno dei test di stress (eseguito per circa 12 ore) otteniamo un errore di seg. Questo a sua volta genera un core dump.

Sfortunatamente il core dump non è molto utile. Il crash si verifica in alcune librerie di sistema che sono collegate dinamicamente (probabilmente pthread o glibc). Il backtrace nel core dump non è utile perché mostra solo il punto di caduta e nessun altro chiamanti (il nostro spazio utente app è costruita con -O0 -g, ma ancora nessuna traccia informazioni indietro):

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. 

Un altro sfortunato -ness è che non possiamo eseguire gdb/gdbserver. gdb/gdbserver continua a rompersi su __nptl_create_event. Vedendo che il test crea thread, timer e distrugge poi ogni 5s è quasi impossibile rimanere seduti per molto tempo a continuare su di essi.

MODIFICA: Un'altra nota, backtrace e backtrace_symbols non è supportata sulla nostra toolchain.

qui:

1. Esiste un modo di intrappolare colpa seg e generare più dati backtrace, puntatori dello stack, stack di chiamate, ecc?

2. C'è un modo per ottenere più dati da un core dump che si è arrestato in modo anomalo in un file .so?

Grazie.

Answer 1

Se tutto il resto fallisce, eseguire il comando utilizzando il debugger!

Basta inserire "gdb" nella forma del normale comando di avvio e immettere "c" ontinue per avviare il processo. Quando l'attività segfaults tornerà al prompt gdb interattivo anziché al core dump. Dovresti quindi essere in grado di ottenere tracce di stack più significative ecc.

Un'altra opzione è usare "traliccio" se disponibile. Questo ti dirà quali chiamate di sistema sono state utilizzate al momento dell'abbandono.

Answer 2

GDB non riesce a trovare l'inizio della funzione in 0x2ab05d18

Qual è a questo indirizzo al momento del crash?

Do info shared e scoprire se esiste una libreria che contiene quell'indirizzo.

La causa più probabile dei tuoi problemi: hai eseguito strip libpthread.so.0 prima di caricarlo sul tuo obiettivo? Non farlo: GDB richiede libpthread.so.0 a non da rimuovere. Se la tua toolchain contiene libpthread.so.0 con simboli di debug (e quindi troppo grandi per la destinazione), esegui strip -g su di essa, non uno completo strip.

Aggiornamento:

info shared prodotto Impossibile accedere memoria all'indirizzo 0x2ab05d18

Ciò significa che GDB non può accedere all'elenco libreria condivisa (che sarebbe poi spiegare la traccia dello stack mancante). La causa più comune: il file binario che ha effettivamente prodotto lo core non corrisponde al file binario che hai fornito a GDB. Una causa meno comune: il core dump è stato troncato (forse a causa del fatto che ulimit -c è impostato troppo basso).