2010-02-09 4 views
12

Mi chiedo se potrebbe essere possibile ottenere un elenco di file/directory che l'applicazione di debug è stata aperta ma non chiusa da GDB stesso?gdb: come elencare i file aperti

Attualmente ho impostato un punto di interruzione e quindi utilizzo un programma esterno come lsof per verificare la presenza di file aperti.

Ma questo approccio è davvero fastidioso.

Ambiente: Debian-Lenny con gdb v6.8

EDIT: Sto chiedendo perché la mia applicazione è il file perde gestisce in alcune situazioni

risposta

6

grazie all'aiuto di Nicola I è stato in grado di automatizzare completamente il compito definendo una macro.

.gdbinit:

define lsof 
    shell rm -f pidfile 
    set logging file pidfile 
    set logging on 
    info proc 
    set logging off 
    shell lsof -p `cat pidfile | perl -n -e 'print $1 if /process (.+)/'` 
end 

document lsof 
    List open files 
end 

ecco un sessione utilizzando la nuova macro (il programma si apre un file nella directory/tmp):

file hello  
break main 
run 
next 
lsof 

uscita:

... 
hello 2683 voku 5r REG 8,1 37357 11110 /home/voku/hello 
hello 2683 voku 6w REG 8,1  0 3358 /tmp/testfile.txt 
... 
+0

Non funziona sul telecomando di destinazione: 'Comando di informazione non definito:" proc ". Prova "informazioni di aiuto" .' :-(. – pevik

0

No, ma è possibile eseguire lsof e filtrare verso il basso per il processo di debug.

12

Su Linux è anche possibile cercare in /proc/<pid>/fd. Per farlo da GDB (ad es. Se vuoi collegarlo a un breakpoint) è piuttosto semplice. Ovviamente puoi usare anche lsof.

(gdb) info proc 
process 5262 
cmdline = '/bin/ls' 
cwd = '/afs/acm.uiuc.edu/user/njriley' 
exe = '/bin/ls' 
(gdb) shell ls -l /proc/5262/fd 
total 0 
lrwx------ 1 njriley users 64 Feb 9 12:45 0 -> /dev/pts/14 
lrwx------ 1 njriley users 64 Feb 9 12:45 1 -> /dev/pts/14 
lrwx------ 1 njriley users 64 Feb 9 12:45 2 -> /dev/pts/14 
lr-x------ 1 njriley users 64 Feb 9 12:45 3 -> pipe:[62083274] 
l-wx------ 1 njriley users 64 Feb 9 12:45 4 -> pipe:[62083274] 
lr-x------ 1 njriley users 64 Feb 9 12:45 5 -> /bin/ls 
(gdb) shell lsof -p 5262 
COMMAND PID USER FD TYPE DEVICE SIZE  NODE NAME 
ls  5262 njriley cwd DIR 0,18 14336 262358 /afs/acm.uiuc.edu/user/njriley 
ls  5262 njriley rtd DIR 8,5 4096  2/
ls  5262 njriley txt REG 8,5 92312  8255 /bin/ls 
ls  5262 njriley mem REG 8,5 14744 441594 /lib/libattr.so.1.1.0 
ls  5262 njriley mem REG 8,5 9680 450321 /lib/i686/cmov/libdl-2.7.so 
ls  5262 njriley mem REG 8,5 116414 450307 /lib/i686/cmov/libpthread-2.7.so 
ls  5262 njriley mem REG 8,5 1413540 450331 /lib/i686/cmov/libc-2.7.so 
ls  5262 njriley mem REG 8,5 24800 441511 /lib/libacl.so.1.1.0 
ls  5262 njriley mem REG 8,5 95964 441580 /lib/libselinux.so.1 
ls  5262 njriley mem REG 8,5 30624 450337 /lib/i686/cmov/librt-2.7.so 
ls  5262 njriley mem REG 8,5 113248 441966 /lib/ld-2.7.so 
ls  5262 njriley 0u CHR 136,14    16 /dev/pts/14 
ls  5262 njriley 1u CHR 136,14    16 /dev/pts/14 
ls  5262 njriley 2u CHR 136,14    16 /dev/pts/14 
ls  5262 njriley 3r FIFO 0,6   62083274 pipe 
ls  5262 njriley 4w FIFO 0,6   62083274 pipe 
ls  5262 njriley 5r REG 8,5 92312  8255 /bin/ls 
+0

c'è un modo per automatizzare questo? –

+1

È possibile allegare un elenco di comandi breakpoint (http://sourceware.org/gdb/current/onlinedocs/gdb/Break-Commands.html) a qualsiasi punto di interruzione, eseguendo quindi lsof su un punto di interruzione. Se hai bisogno di tracciare dove sono stati aperti i fds, puoi anche provare l'opzione --track-fds di valgrind. –

0

Se lsof non è disponibile sul tuo sistema (ho avuto questo problema), puoi usare gdb info os files. Stampa informazioni sui file aperti per tutti i processi.