[C] Problemi di deallocazione della memoria

[fracarro]

Salve ragazzi, ultimamente sto lavorando su un codice che utilizza delle tabelle hash e ho riscontrato dei problemi nella deallocazione della memoria. La tabella hash è un semplice array di puntatoti a liste concatenate (singola concatenazione). Di seguito vi riporto la struttura dell'item:

typedef struct hashrec
{
char *word;
struct hashrec *next;
int costo;
int lb;

} HASHREC;

Ora, dopo aver inserito 2.000.000 di elementi nella tabella il mio codice chiama la seguente funzione per distruggere la tabella:

void
HshKill(HASHREC **ht, long tsize)
{
int i;
HASHREC *htmp, *hprv;

for( i=0 ; i<tsize; i++ ){
if(ht[i]!= NULL){
for(hprv = ht[i], htmp=ht[i]->next; htmp != NULL; htmp = htmp->next ){
free(hprv->word);
free(hprv);
hprv = htmp;
}
free(hprv->word);
free(hprv);
//ht[i] = (HASHREC *) NULL;
}
}
free(ht);
}

A questo punto sorge il problema. Se non utilizzo la tabella hash nel mio codice, il programma a runtime utilizza al più lo 0.5% della memoria di sistema mentre con la tabella arriva anche al 15%, e fin qui tutto bene (ciò significa che tutta la memoria viene richiesta dalla tabella).

Ho inserito una getchar() prima della hshkill e una subito dopo per monitorare, tramite il comando shell "htop", se la memoria venisse effettivamente rilasciata e ciò non accade. In pratica dal 15% passa al 14% mentre io mi aspetto che scenda intorno all 1% dato che era la tabella hash ad occupare tutta quella memoria. Ho verificato anche tramite il pmap (ed il monitor di sistema della ubuntu) se la memoria venisse rilasciata dal mio processo ma ciò non accade come mai? Inoltre:

- conoscete per caso dei debugger grafici che mostrano la dimensione della memoria utilizzata dalle strutture di un programma? (lavoro sotto linux)
- La memoria deallocata tramite la free DEVE ritornare "immediatamente" al sistema?

Grazie per l'aiuto.

[trallallero]

- conoscete per caso dei debugger grafici che mostrano la dimensione della memoria utilizzata dalle strutture di un programma? (lavoro sotto linux)
Assolutamente valgrind (http://http://valgrind.org/), il migliore che io sappia.
Non è grafico ma ti dice vita morte e miracoli di tutta la memoria (e non solo) usata dal programma ;)

[fracarro]

Assolutamente valgrind (http://http://valgrind.org/), il migliore che io sappia.
Non è grafico ma ti dice vita morte e miracoli di tutta la memoria (e non solo) usata dal programma ;)

Lo conosco anche io perchè è utilissimo per il profiling del codice. Accoppiato al kcachegrind ti permette di avere un'interfaccia grafica con le info sui tempi di cpu utilizzati in ogni parte del codice.

Ad ogni modo ritornando a noi, ho tolto qualche accesso "inappropriato" in memoria e adesso il valgrind (lanciato con i comandi: valgrind --tool=memcheck -v --leak-check=full --show-reachable=yes --track-origins=yes ) mi riporta questa situazione:

==7832==
==7832== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 1)
--7832--
--7832-- supp: 3 dl-hack3-cond-1
==7832== malloc/free: in use at exit: 4,235,557 bytes in 100,581 blocks.
==7832== malloc/free: 477,723 allocs, 377,142 frees, 72,994,157 bytes allocated.
==7832==
==7832== searching for pointers to 100,581 not-freed blocks.
==7832== checked 50,160,688 bytes.
==7832==
==7832== 12 bytes in 1 blocks are still reachable in loss record 1 of 37
==7832== at 0x4C232CB: malloc (vg_replace_malloc.c:207)
==7832== by 0x41AB4C: Initialization(short) (DTSP_v28c_alter.cpp:1132)
==7832== by 0x41FA99: main (DTSP_v28c_alter.cpp:695)
==7832==

...........................................
...........................................
...........................................

==7832==
==7832== 44,352 bytes in 21 blocks are still reachable in loss record 34 of 37
==7832== at 0x4C232CB: malloc (vg_replace_malloc.c:207)
==7832== by 0x41B2C7: Initialization(short) (DTSP_v28c_alter.cpp:1241)
==7832== by 0x41FA99: main (DTSP_v28c_alter.cpp:695)
==7832==
==7832==
==7832== 569,410 bytes in 50,249 blocks are still reachable in loss record 35 of 37
==7832== at 0x4C232CB: malloc (vg_replace_malloc.c:207)
==7832== by 0x41BDD1: hashinsert(hashrec**, char*, long, int, int) (hashtable2.c:117)
==7832== by 0x41C266: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:1580)
==7832== by 0x41E8EF: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2222)
==7832== by 0x41EA7A: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2253)
==7832== by 0x41ECA9: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2285)
==7832== by 0x41ECA9: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2285)
==7832== by 0x41ECA9: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2285)
==7832== by 0x41ECA9: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2285)
==7832== by 0x41ECA9: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2285)
==7832== by 0x41EC19: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2281)
==7832== by 0x41EC19: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2281)
==7832==
==7832==
==7832== 1,205,976 bytes in 50,249 blocks are still reachable in loss record 36 of 37
==7832== at 0x4C232CB: malloc (vg_replace_malloc.c:207)
==7832== by 0x41BDBB: hashinsert(hashrec**, char*, long, int, int) (hashtable2.c:116)
==7832== by 0x41C266: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:1580)
==7832== by 0x41E8EF: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2222)
==7832== by 0x41EA7A: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2253)
==7832== by 0x41ECA9: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2285)
==7832== by 0x41ECA9: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2285)
==7832== by 0x41ECA9: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2285)
==7832== by 0x41ECA9: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2285)
==7832== by 0x41ECA9: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2285)
==7832== by 0x41EC19: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2281)
==7832== by 0x41EC19: Visita_sottoalbero(int, int, int, int, int) (DTSP_v28c_alter.cpp:2281)
==7832==
==7832==
==7832== 2,400,000 bytes in 2 blocks are still reachable in loss record 37 of 37
==7832== at 0x4C232CB: malloc (vg_replace_malloc.c:207)
==7832== by 0x41652C: inithashtable(long) (hashtable2.c:68)
==7832== by 0x41AAF4: Initialization(short) (DTSP_v28c_alter.cpp:1128)
==7832== by 0x41FA99: main (DTSP_v28c_alter.cpp:695)
==7832==
==7832== LEAK SUMMARY:
==7832== definitely lost: 0 bytes in 0 blocks.
==7832== possibly lost: 0 bytes in 0 blocks.
==7832== still reachable: 4,235,557 bytes in 100,581 blocks.
==7832== suppressed: 0 bytes in 0 blocks.
--7832-- memcheck: sanity checks: 1733 cheap, 41 expensive
--7832-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--7832-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10
--7832-- memcheck: auxmaps_L2: 0 searches, 0 nodes
--7832-- memcheck: SMs: n_issued = 371 (5936k, 5M)
--7832-- memcheck: SMs: n_deissued = 0 (0k, 0M)
--7832-- memcheck: SMs: max_noaccess = 524287 (8388592k, 8191M)
--7832-- memcheck: SMs: max_undefined = 18 (288k, 0M)
--7832-- memcheck: SMs: max_defined = 980 (15680k, 15M)
--7832-- memcheck: SMs: max_non_DSM = 371 (5936k, 5M)
--7832-- memcheck: max sec V bit nodes: 0 (0k, 0M)
--7832-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
--7832-- memcheck: max shadow mem size: 10080k, 9M
--7832-- ocacheL1: 1,796,967,070 refs 2,735,223 misses (0 lossage)
--7832-- ocacheL1: 1,790,283,308 at 0 3,948,539 at 1
--7832-- ocacheL1: 0 at 2+ 2,766,071 move-fwds
--7832-- ocacheL1: 100,663,296 sizeB 67,108,864 useful
--7832-- ocacheL2: 3,379,482 refs 2,735,223 misses
--7832-- ocacheL2: 0 max nodes 0 curr nodes
--7832-- niacache: 13,468,699 refs 112,580 misses
--7832-- translate: fast SP updates identified: 3,289 ( 86.1%)
--7832-- translate: generic_known SP updates identified: 325 ( 8.5%)
--7832-- translate: generic_unknown SP updates identified: 202 ( 5.2%)
--7832-- tt/tc: 73,192 tt lookups requiring 73,735 probes
--7832-- tt/tc: 73,192 fast-cache updates, 2 flushes
--7832-- transtab: new 5,361 (195,424 -> 3,821,411; ratio 195:10) [0 scs]
--7832-- transtab: dumped 0 (0 -> ??)
--7832-- transtab: discarded 0 (0 -> ??)
--7832-- scheduler: 173,342,140 jumps (bb entries).
--7832-- scheduler: 1,733/926,482 major/minor sched events.
--7832-- sanity: 1734 cheap, 41 expensive checks.
--7832-- exectx: 12,289 lists, 9,014 contexts (avg 0 per list)
--7832-- exectx: 970,036 searches, 1,002,844 full compares (1,033 per 1000)
--7832-- exectx: 151,479 cmp2, 3 cmp4, 0 cmpAll
--7832-- errormgr: 40 supplist searches, 2,949 comparisons during search
--7832-- errormgr: 3 errlist searches, 3 comparisons during search


Il fatto che la memoria delle due tabelle hash non venga esplicitamente deallocata alla fine del codice non mi interessa tanto lo farà il sistema per me. Per caso tu ci vedi qualche altro errore?
(Ripeto, il mio problema è che se durante la computazione dealloco tutta la tabella la memoria non viene liberata).

[trallallero]

Ci vedo solo che non deallochi un bel niente perche' e' pieno di
"n bytes in n blocks are still reachable in loss record n of n" e mi preoccuperei invece fossi in te.
Se non e' troppo lungo perche' non posti il programma cosi' gli do un occhio ?
Ormai programmo solo in C++ e un po' di sano e vecchio C non mi dispiacerebbe :D


PS: ma perche' da ieri non mi funzionano piu' i caratteri accentati su 'sto cesso di Windows XP ??? :muro:

[Stev-O]

avrai una macchina virtuale in esecuzione :D

es io con virtualbox in xp non riesco più a fare la @ :O

cmq per il codice non mi piace molto la condizione di NULL sul for

riesci a sostituire con qualcos'altro ?

[fracarro]

Ci vedo solo che non deallochi un bel niente perche' e' pieno di
"n bytes in n blocks are still reachable in loss record n of n" e mi preoccuperei invece fossi in te.


Se ho capito bene il significato di quel warning del valgrind, semplicemente mi avverte che ci sono zone di memoria a cui io posso ancora accedere tramite i miei puntatori (reachable) ma che non dealloco prima del termine del codice.
In effetti questo per me non è un problema perchè arrivato alla fine del codice deallocare le tabelle prima di uscire mi farebbe solo perdere tempo per un'operazione che un secondo dopo farebbe il sistema al posto mio (so che la cosa non è elegante comunque). Ce ne sono più di uno perchè oltre alle due tabelle ho altri array allocati dinamicamente che utilizzo in tutto il codice e da ciò nasce la sfilza di warning.


Se non e' troppo lungo perche' non posti il programma cosi' gli do un occhio ?
Ormai programmo solo in C++ e un po' di sano e vecchio C non mi dispiacerebbe :D

PS: ma perche' da ieri non mi funzionano piu' i caratteri accentati su 'sto cesso di Windows XP ??? :muro:

Le dimensioni del codice sono spropositate e la sua struttura lo rende alquanto illegibile (a causa di un uso massiccio delle variabili globali). Se però sei curioso puoi trovare l'implementazione originale della tabella hash qui: http://www.csse.unimelb.edu.au/~jz/resources/structures.zip

mentre in allegato c'è la mia versione leggermente modificata che include la funzione di kill e di ingrandimento della tabella. Ti basta includere solo il mio file in un semplice codice c inserire qualche centinaia di migliaia di elementi nella tabella e verificare con la hshkill se ti libera la memoria.

avrai una macchina virtuale in esecuzione :D

es io con virtualbox in xp non riesco più a fare la @ :O

cmq per il codice non mi piace molto la condizione di NULL sul for

riesci a sostituire con qualcos'altro ?

Solitamente viene messo a null il puntatore all'ultimo elemento della lista proprio per sapere quando la lista finisce. Alternativamente potrei far puntare il next a se stesso se sono l'ultimo nodo ma non credo comunque che crei problemi il null.

[trallallero]

cmq per il codice non mi piace molto la condizione di NULL sul for

riesci a sostituire con qualcos'altro ?
Invece a me non piace il font, riesci a mettere un Times New Roman ? :D
Guarda che e' normale usare il NULL come terminatore.

@fracarro: ok, ma lo guardo domani, e' un po' tardino :zzz:

[Stev-O]

è normale ma se vedi l'istruzione successiva rischi discavalcarlo il null

[fracarro]

è normale ma se vedi l'istruzione successiva rischi discavalcarlo il null

Se intendi questa istruzione "htmp = htmp->next", non c'è il pericolo di scavalcarlo perchè l'istruzione viene eseguita alla fine di un ciclo for eseguito a condizione che htmp sia diverso da NULL. Quando questa condizione non è più valida si esce dal for senza eseguire quella istruzione.

[fracarro]

Problema risolto.

Purtroppo i comandi shell linux funzionano male dato che non segnalano correttamente le informazioni riguardanti la memoria. Ho installato il netbeans e lanciato il programma nel suo ambiente dove tra le altre cose viene rilevata la memoria effettivamente usata dal programmadurante l'esecuzione. Ebbene, quando venivano invocate le funzioni di hshkill la memoria si è quasi azzerata (come doveva essere) mentre il top, htop, pmap e free nelle shell linux indicavano che solo una piccola parte della memoria (2%) era stata rilasciata attribuendo quindi al processo un'altro 8% di memoria occupata.

Comunque grazie trallallero e Stev-O per l'aiuto.

[trallallero]

Ma quale grazie! t'ho detto che l'avrei guardato oggi ma mi sono completamente dimenticato :stordita:
Scusa.

[fracarro]

Ma quale grazie! t'ho detto che l'avrei guardato oggi ma mi sono completamente dimenticato :stordita:
Scusa.

Di la verità, eri impegnato a fare baruffe nella sezione politica vero?

A parte gli scherzi, visto questo brutta sorpresa dei comandi shell riguardo l'impiego della memoria tu per caso conosci altri modi (al di fuori del netbeans) per sapere quanta memoria un processo occupa "effettivamente" secondo per secondo?

[trallallero]

Di la verità, eri impegnato a fare baruffe nella sezione politica vero?
No (quello solo nei ritagli di tempo), sto studiando il mondo "plugins" ... anzi, se ne sai qualcosa sputa l'osso :D

A parte gli scherzi, visto questo brutta sorpresa dei comandi shell riguardo l'impiego della memoria tu per caso conosci altri modi (al di fuori del netbeans) per sapere quanta memoria un processo occupa "effettivamente" secondo per secondo?
io uso:
top
poi quando è partito il programma digiti s
appare: Change delay from 3.0 to:
e digiti 1 per un secondo ma puoi anche digitare 0.1 per un decimo di secondo, per esempio.

[trallallero]

Ne ho trovato uno dedicato proprio all'analisi della memoria:
http://www.berthels.co.uk/exmap/download/exmap-0.9.tgz

Però a me da un errore in compilazione (colpa dell'ultima versione di gcc che rompe le palle sui char* in c++) quindi ho dovuto modificare "exmtool.cpp" da
struct command
{
char *command;
Handler handler;
char *usage;
}
a
struct command
{
const char *command;
Handler handler;
const char *usage;
}

poi ho compilato (leggi il README - se hai problemi chiedimi pure, sicuramente ti mancherà qualche package tipo gtkmm o pcre) e lanciato ... minkia, ti dice veramente tutto :eek:

[fracarro]

io uso:
top
poi quando è partito il programma digiti s
appare: Change delay from 3.0 to:
e digiti 1 per un secondo ma puoi anche digitare 0.1 per un decimo di secondo, per esempio.

Purtroppo il top appartiene alla categoria di comandi che "sembra" darti le giuste informazioni ma invece non lo fa. Insieme al top, ci sono l'htop, il pmap ed il free. Nel mio caso mi hanno fatto perdere due giorni cercando un leak memory che non esisteva solo perchè erroneamente mi segnalavano memoria associata al mio processo che invece era stata correttamente liberata. Ad ogni modo se usi il top ti consiglio caldamente l'htop (si installa banalmente dal synaptic) è una versione del top migliorato che permette anche di ordinare i processi per colonne (io lo uso per ordinare in base all'uso della cpu o della memoria).

Ne ho trovato uno dedicato proprio all'analisi della memoria:
http://www.berthels.co.uk/exmap/download/exmap-0.9.tgz

................

poi ho compilato (leggi il README - se hai problemi chiedimi pure, sicuramente ti mancherà qualche package tipo gtkmm o pcre) e lanciato ... minkia, ti dice veramente tutto :eek:

Sarei molto curioso di provare questo tool. L'ho scaricato e provato ad installare (cambiando anche il puntatore a caratteri come da te indicato) ma quando lancio il make test mi dai il seguente errore:

File::load - failed to load header: /etc/motd
File::load - failed to load header: /proc/1/auxv
Vma::get_pages_for_range - start pgnum out of range: 0, 0 [vsyscall]
sizes_for_mem_range: Can't get pages for range (ffffffffff600000,ffffffffff601000)
t_exmap: /usr/include/boost/shared_ptr.hpp:315: T* boost::shared_ptr<T>::operator->() const [with T = Exmap::Sizes]: Assertion `px != 0' failed.
Aborted
./t_range 133/133
./t_elf 107/107
./t_pcre 22/22
./t_exmap 24/24
WARNING: Ran fewer tests than planned: 24 < 197
./t_artsd 13/13
--------------------------------
FAIL: ./t_exmap ran 24 but 197 were planned
make[1]: Leaving directory `/home/pippo/exmap-0.9/exmap-0.9/src'


Poichè era un comando opzionale ho provato comunque a lanciare il programma con " ./src/gexmap" e mi da il seguente errore:

FAIL: ./t_exmap ran 24 but 197 were planned
make[1]: Leaving directory `/home/pippo/exmap-0.9/exmap-0.9/src'
root@mostriciattolo-desktop:~/exmap-0.9/exmap-0.9# ./src/gexmap
Vma::get_pages_for_range - start pgnum out of range: 0, 0 [vsyscall]
sizes_for_mem_range: Can't get pages for range (ffffffffff600000,ffffffffff601000)
gexmap: /usr/include/boost/shared_ptr.hpp:315: T* boost::shared_ptr<T>::operator->() const [with T = Exmap::Sizes]: Asserzione 'px != 0' fallita.
Aborted


Cos'è che non va?

[trallallero]

Anche a me da qualche warning del genere quando lo compilo e lancio il make test, ma alla fine parte e funziona bene.
Visto che rompe cosi' tanto lo considererei escluso dai programmi affidabili, ma su qualche sito ho letto che e' il migliore ... ci sara' un motivo.

Comunque vedo che ti da un problema lo shared pointer di boost, magari hai una versione di boost non aggiornata.
Ma fino a lunedi non posso dirti che versione uso io al lavoro.

boost devo dire che da spesso qulache problema. Noi siamo passati ormai a QT quindi non posso aiutarti molto su quel problema (ma ci posso provare se vuoi e stavolta mi metto un promemoria :D).

[fracarro]

Anche a me da qualche warning del genere quando lo compilo e lancio il make test, ma alla fine parte e funziona bene.
Visto che rompe cosi' tanto lo considererei escluso dai programmi affidabili, ma su qualche sito ho letto che e' il migliore ... ci sara' un motivo.

Comunque vedo che ti da un problema lo shared pointer di boost, magari hai una versione di boost non aggiornata.
Ma fino a lunedi non posso dirti che versione uso io al lavoro.

boost devo dire che da spesso qulache problema. Noi siamo passati ormai a QT quindi non posso aiutarti molto su quel problema (ma ci posso provare se vuoi e stavolta mi metto un promemoria :D).

Il fatto è che boost l'ho appena installato con il comando apt-get install libboost-dev proprio perchè richiesto dal pacchetto quindi credo non ci siano versioni più aggiornate. Comunque vedrò domani di informarmi meglio perchè il tool mi è molto molto utile. (P.S. poichè il computer con linux lo sto gestendo il remoto tramite sftp, potrebbe essere questa la causa dell'errore? uso xming per lanciare la grafica linux sotto windows).

[trallallero]

Il fatto è che boost l'ho appena installato con il comando apt-get install libboost-dev proprio perchè richiesto dal pacchetto quindi credo non ci siano versioni più aggiornate. Comunque vedrò domani di informarmi meglio perchè il tool mi è molto molto utile. (P.S. poichè il computer con linux lo sto gestendo il remoto tramite sftp, potrebbe essere questa la causa dell'errore? uso xming per lanciare la grafica linux sotto windows).

Ah beh, se usi Windows per lanciare Linux te la cerchi :asd:
Scherzo, pero' non so proprio se quello possa essere il problema :boh:

[fracarro]

Ah beh, se usi Windows per lanciare Linux te la cerchi :asd:
Scherzo, pero' non so proprio se quello possa essere il problema :boh:

In effetti non è una grande idea ma a volte è comodo gestire in remoto da windows un computer linux. Ad ogni modo questa mattina ho installato anch ela ubuntu 9.04 sul mio portatile con tutte le librerie che servivano per far funzionare l'exmap ma adesso mi da problemi durante il make.

Premessa. E' possibile installare direttamente tramite il synaptic l'exmap ma sorgono problemi a runtine perchè bisogno compilare un modulo per il kernel e quindi ho desistito.
Ho scaricato l'ultima versione del programma la 0.10, scompatto il file e lancio il make ottenendo i seguenti errori (che ottengo anche con la 0.9):


...................................
/home/fracar/Scrivania/exmap-0.10/kernel/exmap.c: In function ‘setup_from_pid’:
/home/fracar/Scrivania/exmap-0.10/kernel/exmap.c:395: error: implicit declaration of function ‘find_task_by_pid’
/home/fracar/Scrivania/exmap-0.10/kernel/exmap.c:395: warning: assignment makes pointer from integer without a cast
/home/fracar/Scrivania/exmap-0.10/kernel/exmap.c: In function ‘init_module’:
/home/fracar/Scrivania/exmap-0.10/kernel/exmap.c:510: error: ‘proc_root’ undeclared (first use in this function)
/home/fracar/Scrivania/exmap-0.10/kernel/exmap.c:510: error: (Each undeclared identifier is reported only once
/home/fracar/Scrivania/exmap-0.10/kernel/exmap.c:510: error: for each function it appears in.)
/home/fracar/Scrivania/exmap-0.10/kernel/exmap.c: In function ‘cleanup_module’:
/home/fracar/Scrivania/exmap-0.10/kernel/exmap.c:535: error: ‘proc_root’ undeclared (first use in this function)
make[3]: *** [/home/fracar/Scrivania/exmap-0.10/kernel/exmap.o] Errore 1
make[2]: *** [_module_/home/fracar/Scrivania/exmap-0.10/kernel] Errore 2
make[2]: uscita dalla directory «/usr/src/linux-headers-2.6.28-14-generic»
make[1]: *** [kernel_modules] Errore 2
......................................


Ci capisci nulla?

[trallallero]

Ci capisci nulla?
Penso che siano errori dovuti ad un compilatore piu' rompicoglioni, tutto qua'.
Pero' se pure il programma e' cosi' difficile da compilare (e pare sia il migliore, bah) lo scarterei, poco affidabile.
Al lavoro, l'unico posto dove ho installato exmap, abbiamo ubuntu 8.04 e non posso aggiornarlo perche' quando aggiorniamo lo facciamo tutti insieme, per non avere problemi nei progetti, e tra gli aggiornamenti di ubuntu (che pure coordiniamo) c'e' in attesa un gcc<qualcosa>, quindi forse con ubuntu 9 hai un compilatore piu' recente.
Ti consiglio di cercare un'alternativa a 'sto punto.

PS: ho capito ed assimilato i plugins, mi si e' aperto un mondo nuovo :D

[fracarro]

Penso che siano errori dovuti ad un compilatore piu' rompicoglioni, tutto qua'.
Pero' se pure il programma e' cosi' difficile da compilare (e pare sia il migliore, bah) lo scarterei, poco affidabile.
Al lavoro, l'unico posto dove ho installato exmap, abbiamo ubuntu 8.04 e non posso aggiornarlo perche' quando aggiorniamo lo facciamo tutti insieme, per non avere problemi nei progetti, e tra gli aggiornamenti di ubuntu (che pure coordiniamo) c'e' in attesa un gcc<qualcosa>, quindi forse con ubuntu 9 hai un compilatore piu' recente.
Ti consiglio di cercare un'alternativa a 'sto punto.

PS: ho capito ed assimilato i plugins, mi si e' aperto un mondo nuovo :D


Infatti leggendo su internet ho capito che riguarda i nuovi kernel e bisognerebbe recuperare delle patch per farlo funzionare. Vabbè desisto, prima o poi uscirà qualche programma simile.

Un'ultima domanda. Sfruttando il sun studio all'interno del profiler del netbeans, mi segnala a runtime dei leak memory che non erano stati rilevati da valgrind (strano però). Sono andato a controllare e mi segnala questo:


typedef struct hashitem {
char *key;
int costo_parziale;
int lb_tour;
} item, *itemptr;

item temp_item;

void *mydupe(void *x){

itemptr y = (itemptr) x;
itemptr newitem;

newitem = (itemptr) malloc(sizeof(item));

if(newitem){
newitem->key = (char*) malloc(sizeof(char)*(1+my_strlen(y->key)));
if (newitem->key != NULL){
strcpy(newitem->key,y->key);
newitem->costo_parziale = y->costo_parziale;
newitem->lb_tour = y->lb_tour;
}
else{
free(newitem);
newitem = NULL;
}
}

return newitem;
}

static void* *maketbl(unsigned long newsize)
{
unsigned long i;
void* *newtbl;

newtbl = malloc(newsize * sizeof *newtbl);
if (newtbl) {
for (i = 0; i < newsize; i++)
newtbl[i] = NULL;
}
return newtbl;
} /* maketbl */



Le linee blu rappresentano le istruzioni che secondo il sun studio producono "bytes leaked". Alla fine è solo qualche mega di memoria che viene sprecato, ma non capisco perchè? Si perde memoria a causa del cast da void a un altro tipo di puntatore?

P.S. Ma plugins per cosa?

[trallallero]

Così al volo non vedo errori :boh:

Forse te li segnala perchè la funzione alloca ma non dealloca (giustamente), ma non ne sono sicuro.

Plugins in generale, sono una figata. Son partito da un esempio (orrendo perchè l'applicazione sa cosa faranno i plugins :rolleyes: ) di qt e sono arrivato a capire che non ci sono limiti.
L'applicazione main carica in realtime i plugins, gli da la propria istanza e il plugin fa quello che vuole.
In pratica controlli l'applicazione main dal plugin o comunque fai quello che vuoi (tipo Eclipse) :D

[fracarro]

Forse ho trovato un modo per sapere qual'è la memoria reale associata ad un processo (devo vedere ancora se mi rivela la deallocazione della memoria del mio programma però).


Ho scaricato e compilato i seguenti due pacchetti (nell'ordine):

http://search.cpan.org/CPAN/authors/id/O/OP/OPI/Class-Member-1.3.tar.gz
http://search.cpan.org/CPAN/authors/id/O/OP/OPI/Linux-Smaps-0.06.tar.gz

Poi ho copiato il seguente script perl (che serve solo per mettere in una forma leggibile i dati riguardo la memoria del processo):

#!/usr/bin/perl
#smaps.pl
#typical usage is as follows :
# smaps.pl pid

use Linux::Smaps;

my $pid=shift @ARGV;
unless ($pid) {
print "./smem.pl <pid>\n";
exit 1;
}
my $map=Linux::Smaps->new($pid);
my @VMAs = $map->vmas;

format STDOUT =
VMSIZE: @######## kb
$map->size
RSS: @######## kb total
$map->rss
@######## kb shared
$map->shared_clean + $map->shared_dirty
@######## kb private clean
$map->private_clean
@######## kb private dirty
$map->private_dirty
.

write;

printPrivateMappings ();
printSharedMappings ();

sub sharedMappings () {
return grep { ($_->shared_clean + $_->shared_dirty) > 0 } @VMAs;
}

sub privateMappings () {
return grep { ($_->private_clean + $_->private_dirty) > 0 } @VMAs;
}

sub printPrivateMappings ()
{
$TYPE = "PRIVATE MAPPINGS";
$^ = 'SECTION_HEADER';
$~ = 'SECTION_ITEM';
$- = 0;
$= = 100000000;
foreach $vma (sort {-($a->private_dirty <=> $b->private_dirty)}
privateMappings ()) {
$size = $vma->size;
$dirty = $vma->private_dirty;
$clean = $vma->private_clean;
$file = $vma->file_name;
write;
}
}

sub printSharedMappings ()
{
$TYPE = "SHARED MAPPINGS";
$^ = 'SECTION_HEADER';
$~ = 'SECTION_ITEM';
$- = 0;
$= = 100000000;

foreach $vma (sort {-(($a->shared_clean + $a->shared_dirty)
<=>
($b->shared_clean + $b->shared_dirty))}
sharedMappings ()) {

$size = $vma->size;
$dirty = $vma->shared_dirty;
$clean = $vma->shared_clean;
$file = $vma->file_name;
write;


}
}

format SECTION_HEADER =
@<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
$TYPE
@>>>>>>>>>> @>>>>>>>>>> @>>>>>>>>> @<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
"vmsize" "rss clean" "rss dirty" "file"
.

format SECTION_ITEM =
@####### kb @####### kb @####### kb @<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
$size $clean $dirty $file
.


A questo punto basta lanciare lo script seguito dal pid del processo e vengono elencate le info sulla memoria del processo.

Ho trovato queste info qui: http://bmaurer.blogspot.com/2006/03/memory-usage-with-smaps.html

Spero possano servire anche ad altri.

Così al volo non vedo errori :boh:

Forse te li segnala perchè la funzione alloca ma non dealloca (giustamente), ma non ne sono sicuro.


Purtroppo non ne ho idea. Potrebbero essere i puntatori void? Ci vorrebbe qualche esperto di memory leak. Strano che gugoxx e cionci non si siano fatti sentire, solitamente hanno una soluzione per tutto.