2010-02-09 7 views
12

Zastanawiam się, czy może być możliwe uzyskanie listy plików/katalogów, które debugowana aplikacja została otwarta, ale nie zamknięta od samego GDB?gdb: howto lista otwartych plików

Obecnie ustawiam punkt przerwania, a następnie używam zewnętrznego programu, takiego jak lsof, w celu sprawdzenia otwartych plików.

Ale to podejście jest naprawdę denerwujące.

Środowisko: Debian Lenny z gdb-v6.8

EDIT: Pytam, ponieważ mój wniosek jest nieszczelny plik uchwyty w niektórych sytuacjach

Odpowiedz

6

dzięki pomocy Mikołaja udało mi się w pełni zautomatyzować zadanie, definiując makro.

.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 

o to sesja przy użyciu nowego makra (program otwiera plik w katalogu/tmp):

file hello  
break main 
run 
next 
lsof 

wyjściowy:

... 
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

Nie działa na zdalnym sterowniku: 'Niezdefiniowana komenda info:" proc ". Spróbuj "help info". ":-(. – pevik

0

Nie, ale można uruchomić lsof i filtrować dół debugowany proces.

12

W systemie Linux można również po prostu zaglądać pod numer /proc/<pid>/fd. Aby to zrobić z GDB (np. Jeśli chcesz dołączyć go do punktu przerwania) jest całkiem proste. Oczywiście możesz też użyć 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

Czy można to zautomatyzować? –

+1

Możesz dołączyć listę poleceń punktu przerwania (http://sourceware.org/gdb/current/onlinedocs/gdb/Break-Commands.html) do dowolnego punktu przerwania, uruchamiając lsof na punkcie przerwania. Jeśli chcesz śledzić, gdzie zostały otwarte fds, możesz również spróbować opcji valgrind --track-fds. –

0

Jeśli lsof nie jest dostępny w twoim systemie (miałem taki problem), możesz użyć gdb info os files. Drukuje informacje o otwartych plikach dla wszystkich procesów.