Stack frame danneggiato GDB - Come eseguire il debug?

Ho la seguente traccia dello stack. È possibile ricavare qualcosa di utile da questo per il debug?

Program received signal SIGSEGV, Segmentation fault.
0x00000002 in ?? ()
(gdb) bt
#0  0x00000002 in ?? ()
#1  0x00000001 in ?? ()
#2  0xbffff284 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) 

Da dove iniziare a guardare il codice quando otteniamo un file Segmentation fault e la traccia dello stack non è così utile?

NOTA: se inserisco il codice, gli esperti SO mi daranno la risposta. Voglio seguire la guida di SO e trovare la risposta da solo, quindi non sto pubblicando il codice qui. Scuse.

Questi indirizzi fasulli (0x00000002 e simili) sono in realtà valori PC, non valori SP. Ora, quando ottieni questo tipo di SEGV, con un indirizzo PC fasullo (molto piccolo), il 99% delle volte è dovuto alla chiamata tramite un puntatore a funzione fasullo. Si noti che le chiamate virtuali in C ++ vengono implementate tramite puntatori a funzione, quindi qualsiasi problema con una chiamata virtuale può manifestarsi allo stesso modo.

Un'istruzione di chiamata indiretta spinge semplicemente il PC dopo la chiamata nello stack e quindi imposta il PC sul valore target (falso in questo caso), quindi se questo è quello che è successo, puoi facilmente annullarlo estraendo manualmente il PC dallo stack . Nel codice x86 a 32 bit devi solo fare:

(gdb) set $pc = *(void **)$esp
(gdb) set $esp = $esp + 4

Con il codice x86 a 64 bit è necessario

(gdb) set $pc = *(void **)$rsp
(gdb) set $rsp = $rsp + 8

Quindi, dovresti essere in grado di eseguire un file bt e capire dove si trova realmente il codice.

Il restante 1% delle volte, l'errore sarà dovuto alla sovrascrittura dello stack, di solito per overflow di un array memorizzato nello stack. In questo caso, potresti essere in grado di ottenere maggiore chiarezza sulla situazione utilizzando uno strumento come valgrind

Se la situazione è abbastanza semplice, la risposta di Chris Dodd è la migliore. Sembra che sia saltato attraverso un puntatore NULL.

Tuttavia, è possibile che il programma si sia sparato al piede, al ginocchio, al collo e all'occhio prima di schiantarsi: ha sovrascritto la pila, incasinato il puntatore del fotogramma e altri mali. Se è così, è improbabile che sbrogliare l'hashish ti mostri patate e carne.

La soluzione più efficiente sarà eseguire il programma nel debugger e passare alle funzioni finché il programma non si arresta in modo anomalo. Una volta identificata una funzione che si è arrestata in modo anomalo, ricominciare da capo ed entrare in quella funzione e determinare quale funzione chiama causa l'arresto. Ripeti finché non trovi la singola riga di codice incriminata. Il 75% delle volte la correzione sarà quindi ovvia.

Nell'altro 25% delle situazioni, la cosiddetta linea di codice incriminata è una falsa pista. Risponderà alle condizioni (non valide) impostate molte righe prima, forse migliaia di righe prima. In tal caso, il miglior corso scelto dipende da molti fattori: principalmente dalla tua comprensione del codice e dall'esperienza con esso:

• Forse l'impostazione di un punto di controllo del debugger o l'inserimento di diagnostiche printfsu variabili critiche porterà al necessario A ha!
• Forse la modifica delle condizioni di test con input diversi fornirà maggiori informazioni rispetto al debug.
• Forse un secondo paio di occhi ti costringerà a controllare le tue ipotesi o raccogliere prove trascurate.
• A volte, tutto ciò che serve è andare a cena e pensare alle prove raccolte.

In bocca al lupo!

Supponendo che il puntatore allo stack sia valido ...

Potrebbe essere impossibile sapere esattamente dove si trova il SEGV dal backtrace - penso che i primi due stack frame siano completamente sovrascritti. 0xbffff284 sembra un indirizzo valido, ma i due successivi non lo sono. Per uno sguardo più da vicino allo stack, puoi provare quanto segue:

gdb $ x / 32ga $ rsp

o una variante (sostituire il 32 con un altro numero). Questo stamperà un certo numero di parole (32) a partire dallo stack pointer di dimensioni giganti (g), formattate come indirizzi (a). Digita "help x" per maggiori informazioni sul formato.

Strumentare il codice con alcuni "printf" sentinella potrebbe non essere una cattiva idea, in questo caso.

Guarda alcuni dei tuoi altri registri per vedere se uno di loro ha il puntatore dello stack memorizzato nella cache. Da lì, potresti essere in grado di recuperare una pila. Inoltre, se questo è incorporato, molto spesso lo stack è definito in un indirizzo molto particolare. Usandolo, a volte puoi anche ottenere uno stack decente. Tutto ciò presuppone che quando sei saltato nell'iperspazio, il tuo programma non ha vomitato per tutta la memoria lungo la strada ...

Se si tratta di una sovrascrittura dello stack, i valori potrebbero corrispondere a qualcosa di riconoscibile dal programma.

Ad esempio, mi sono appena ritrovato a guardare la pila

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000000000000342d in ?? ()
#2  0x0000000000000000 in ?? ()

ed 0x342dè 13357, che si è rivelato essere un node-id quando ho estratto i log dell'applicazione per questo. Ciò ha immediatamente aiutato a restringere i siti candidati in cui potrebbe essersi verificata la sovrascrittura dello stack.