[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]

Originariamente inviato da fracarro

- conoscete per caso dei debugger grafici che mostrano la dimensione della memoria utilizzata dalle strutture di un programma? (lavoro sotto linux)

Assolutamente valgrind, 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]

Originariamente inviato da trallallero

Assolutamente valgrind, 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


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

[Stev-O]

avrai una macchina virtuale in esecuzione

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

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

riesci a sostituire con qualcos'altro ?

[fracarro]

Originariamente inviato da 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 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

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

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

Originariamente inviato da Stev-O

avrai una macchina virtuale in esecuzione

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

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]

Originariamente inviato da Stev-O

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 ?
Guarda che e' normale usare il NULL come terminatore.

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

[Stev-O]

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

[fracarro]

Originariamente inviato da Stev-O

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

[fracarro]

Originariamente inviato da trallallero

Ma quale grazie! t'ho detto che l'avrei guardato oggi ma mi sono completamente dimenticato
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]

Originariamente inviato da fracarro

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

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

[fracarro]

Originariamente inviato da trallallero

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

Originariamente inviato da trallallero

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

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

[fracarro]

Originariamente inviato da 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 ).

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]

Originariamente inviato da fracarro

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
Scherzo, pero' non so proprio se quello possa essere il problema

[fracarro]

Originariamente inviato da trallallero

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

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]

Originariamente inviato da fracarro

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