2013-05-09 9 views
5

Su Linux, ho un'applicazione C++ che sta usando dlopen() per caricare alcune librerie condivise, ma sono sospettoso che la versione della libreria condivisa caricata non sia quella che mi aspetto perché il mio codice di traccia di debug non appare essere giustiziato.Come posso verificare un processo in esecuzione per vedere quali librerie condivise sta usando?

C'è un modo per verificare un processo in esecuzione per interrogare tutte le librerie condivise attualmente aperte e il percorso di ciascuna di queste librerie? In altre parole, qualcosa di simile a ldd ma che funziona su un eseguibile in esecuzione e elenca anche le librerie caricate di runtime.

+1

try 'lsof -p _process_id_' – stardust

+3

K Ecco una risposta completa. http://stackoverflow.com/questions/5103443/how-to-check-what-shared-library-is-loaded-at-run-time – stardust

risposta

7

Se si desidera conoscere i file di libreria aperti da un programma, è possibile provare pmap. Per esempio, se vogliamo conoscere le librerie che bash processo 3860 hanno aperto, il risultato potrebbe essere:

3860: bash 
08048000 880K r-x-- /bin/bash 
08124000  4K r---- /bin/bash 
08125000  20K rw--- /bin/bash 
0812a000  20K rw--- [ anon ] 
099ae000 348K rw--- [ anon ] 
b715c000  44K r-x-- /lib/i386-linux-gnu/libnss_files-2.15.so 
b7167000  4K r---- /lib/i386-linux-gnu/libnss_files-2.15.so 
b7168000  4K rw--- /lib/i386-linux-gnu/libnss_files-2.15.so 
b7169000  88K r-x-- /lib/i386-linux-gnu/libnsl-2.15.so 
b717f000  4K r---- /lib/i386-linux-gnu/libnsl-2.15.so 
b7180000  4K rw--- /lib/i386-linux-gnu/libnsl-2.15.so 
b7181000  8K rw--- [ anon ] 
b7183000  28K r-x-- /lib/i386-linux-gnu/libnss_compat-2.15.so 
b718a000  4K r---- /lib/i386-linux-gnu/libnss_compat-2.15.so 
b718b000  4K rw--- /lib/i386-linux-gnu/libnss_compat-2.15.so 
b71a1000  4K r---- /usr/lib/locale/locale-archive 
b71a2000 1428K r---- /usr/lib/locale/locale-archive 
b7307000 2048K r---- /usr/lib/locale/locale-archive 
b7507000  4K rw--- [ anon ] 
b7508000 1676K r-x-- /lib/i386-linux-gnu/libc-2.15.so 
b76ab000  8K r---- /lib/i386-linux-gnu/libc-2.15.so 
b76ad000  4K rw--- /lib/i386-linux-gnu/libc-2.15.so 
b76ae000  16K rw--- [ anon ] 
b76b2000  12K r-x-- /lib/i386-linux-gnu/libdl-2.15.so 
b76b5000  4K r---- /lib/i386-linux-gnu/libdl-2.15.so 
b76b6000  4K rw--- /lib/i386-linux-gnu/libdl-2.15.so 
b76b7000 112K r-x-- /lib/i386-linux-gnu/libtinfo.so.5.9 
b76d3000  8K r---- /lib/i386-linux-gnu/libtinfo.so.5.9 
b76d5000  4K rw--- /lib/i386-linux-gnu/libtinfo.so.5.9 
b76d8000  28K r--s- /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache 
b76df000  40K r-x-- /lib/i386-linux-gnu/libnss_nis-2.15.so 
b76e9000  4K r---- /lib/i386-linux-gnu/libnss_nis-2.15.so 
b76ea000  4K rw--- /lib/i386-linux-gnu/libnss_nis-2.15.so 
b76eb000  8K rw--- [ anon ] 
b76ed000  4K r-x-- [ anon ] 
b76ee000 128K r-x-- /lib/i386-linux-gnu/ld-2.15.so 
b770e000  4K r---- /lib/i386-linux-gnu/ld-2.15.so 
b770f000  4K rw--- /lib/i386-linux-gnu/ld-2.15.so 
bfbbf000 132K rw--- [ stack ] 
total  7152K 

vorrei che sarebbe di aiuto per voi.

+0

Doveva eseguire un programma tramite GDB per tenerlo in vita abbastanza a lungo, ma pmap fa il lavoro. Grazie! – dhardy

Problemi correlati