2010-06-09 20 views
30

Mi piacerebbe sapere se il mio programma sta accedendo a puntatori NULL o memoria stantio.Come posso ottenere GDB per dirmi quale indirizzo ha causato un segfault?

Il backtrace assomiglia a questo:

 
Program received signal SIGSEGV, Segmentation fault. 
[Switching to Thread 0x2b0fa4c8 (LWP 1333)] 
0x299a6ad4 in pthread_mutex_lock() from /lib/libpthread.so.0 
(gdb) bt 
#0 0x299a6ad4 in pthread_mutex_lock() from /lib/libpthread.so.0 
#1 0x0058e900 in ??() 

risposta

47

Con GDB 7 e superiore, è possibile esaminare la struttura $_siginfo che viene compilato quando si verifica il segnale, e determinare l'indirizzo faulting:

(gdb) p $_siginfo._sifields._sigfault.si_addr 

Se mostra (void *) 0x0 (o un piccolo numero) allora avere un dereferenziamento puntatore NULL.

+0

(gdb) p $ _siginfo $ 1 = vuoto Credo SIGINFO non è supportata su questa architettura :( – nornagon

+0

Assicurarsi che si sta utilizzando v7 gdb o superiore ... – To1ne

+0

Usa 'ptype $ _siginfo' per vedere cos'altro c'è nella struttura. – To1ne

0

eseguire il programma in GDB. Quando si verifica il segfault, GDB ti informerà della riga e dell'istruzione del tuo programma, insieme alla variabile e al suo indirizzo associato.

È possibile utilizzare il comando "stampa" (p) in GDB per ispezionare le variabili. Se l'arresto anomalo si è verificato durante una chiamata alla libreria, è possibile utilizzare la serie di comandi "frame" per visualizzare il frame dello stack in questione.

+0

Il segfault non è nel codice a cui ho l'origine. – nornagon

+0

@nornagon: Il comando 'bt' ti mostrerà un backtrace, che ti permetterà di vedere dove ti trovavi nel tuo codice quando l'errore si è verificato. – caf

+0

Sì, lo so, ma non è ancora d'aiuto - era in una chiamata di funzione di libreria con diversi argomenti, e non so quale di quegli argomenti stia causando un segfault. – nornagon

Problemi correlati