Come uscire da gdb se il programma ha successo, si interrompe se il programma va in crash?

Question

Mi sembra di avere una specie di bug multithreading nel mio codice che lo fa arrestare ogni 30 esecuzioni della sua suite di test. La suite di test non è interattiva. Voglio eseguire la mia suite di test in gdb e fare in modo che gdb esca normalmente se il programma esce normalmente o interrompe (e mostra un prompt di debug) se si blocca. In questo modo posso far funzionare ripetutamente la suite di test, andare a prendere una tazza di caffè, tornare indietro e presentare una bella richiesta di debug. Come posso farlo con gdb?

Answer 1

Questo è un po 'hacky, ma si poteva fare:

gdb --eval-command=run --eval-command=quit --args ./a.out 

Se a. out termina normalmente, ti lascerà semplicemente fuori da GDB. Ma se si crash, il programma sarà ancora attivo, in modo da GDB in genere chiederà se si vuole veramente uscire con un inferiore attiva:

Program received signal SIGABRT, Aborted. 
0x00007ffff72dad05 in raise (sig=...) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. 
    in ../nptl/sysdeps/unix/sysv/linux/raise.c 
A debugging session is active. 

    Inferior 1 [process 15126] will be killed. 

Quit anyway? (y or n) 

Come ho detto, non è bella, ma funziona, fino a quando si non aver disattivato la richiesta di uscire con un processo attivo. C'è probabilmente un modo per usare anche il comando quit di gdb: prende un argomento numerico che è il codice di uscita per la sessione di debug. Quindi forse puoi usare --eval-command = "quit stuff", dove roba è una espressione GDB che riflette se l'inferiore è in esecuzione o meno.

Answer 2

Arrestare il core quando si blocca. Se sei su Linux, leggi la pagina man man core e anche la ulimit integrata se stai utilizzando bash.

In questo modo quando si blocca troverete un bel corefile che è possibile alimentare a gdb:

$ ulimit -c unlimited 
$ ... run program ..., gopher coffee (or reddit ;) 
$ gdb progname corefile 

Answer 3

Non si ottiene un file core quando si blocca? Avvia gdb come questo 'gdb -c core' e fai un traceback dello stack.

Più probabilmente vorrete usare Valgrind.

Answer 4

Il modo più semplice è quello di utilizzare il Python API offerto da gdb:

def exit_handler(event): 
    gdb.execute("quit") 

gdb.events.exited.connect(exit_handler) 

Si può anche farlo con una sola riga:

(gdb) gdb.events.exited.connect(lambda x : gdb.execute("quit") 

È inoltre possibile esaminare il codice di ritorno per assicurarsi che sia la codice "normale" previsto con event.exit_code.

Si può usare in combinazione con --eval-command o --command come detto da @acm per registrare il gestore di eventi dalla riga di comando, o con un file .gdbinit.

Answer 5

È inoltre possibile attivare un backtrace quando il programma va in crash e lasciare uscire gdb con il codice di ritorno del processo figlio:

gdb -return-child-result -ex run -ex "thread apply all bt" -ex "quit" --args myProgram -myProgramArg 

Answer 6

creare un file denominato .gdbinit e sarà usato quando viene lanciato gdb.

run 
quit 

eseguito senza opzioni:

gdb --args prog arg1... 

si sta dicendo gdb di correre e uscire, ma dovrebbe interrompere l'elaborazione del file se si verifica un errore.

Answer 7

Se si mettono le seguenti righe nel file ~/.gdbinit, gdb uscirà quando il programma esce con un codice di stato di 0.

python 

def exit_handler (event): 
    if event .exit_code == 0: 
    gdb .execute ("quit") 

gdb .events .exited .connect (exit_handler) 

end 

Quanto sopra è un perfezionamento della risposta di Kevin.