PDA

View Full Version : [C] glibc difettose o cosa?


fbcyborg
11-03-2011, 16:37
Salve a tutti,

è ormai qualche mese che uso un programma scritto da me in C per fare dei test, e in genere nel 99% dei casi ha sempre funzionato.
Ora, ogni volta che lancio il programma ottengo questo:
*** glibc detected *** /home/user/workspace/EncryptFiles/Debug/EncryptFiles: double free or corruption (out): 0x000000000060a8e0 ***
======= Backtrace: =========
/lib/libc.so.6(+0x72b36)[0x7fb257272b36]
/lib/libc.so.6(cfree+0x6c)[0x7fb2572778ec]
/home/user/workspace/EncryptFiles/Debug/EncryptFiles[0x402b3f]
/home/user/workspace/EncryptFiles/Debug/EncryptFiles[0x401a06]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7fb25721ebbd]
/home/user/workspace/EncryptFiles/Debug/EncryptFiles[0x401559]
======= Memory map: ========
00400000-00404000 r-xp 00000000 09:04 2113799 /home/user/workspace/EncryptFiles/Debug/EncryptFiles
00604000-00605000 r--p 00004000 09:04 2113799 /home/user/workspace/EncryptFiles/Debug/EncryptFiles
00605000-00606000 rw-p 00005000 09:04 2113799 /home/user/workspace/EncryptFiles/Debug/EncryptFiles
00606000-00641000 rw-p 00000000 00:00 0 [heap]
7fb250000000-7fb250021000 rw-p 00000000 00:00 0
7fb250021000-7fb254000000 ---p 00000000 00:00 0
7fb254fe5000-7fb254ffb000 r-xp 00000000 09:01 311158 /lib64/libgcc_s.so.1
7fb254ffb000-7fb2551fa000 ---p 00016000 09:01 311158 /lib64/libgcc_s.so.1
7fb2551fa000-7fb2551fb000 r--p 00015000 09:01 311158 /lib64/libgcc_s.so.1
7fb2551fb000-7fb2551fc000 rw-p 00016000 09:01 311158 /lib64/libgcc_s.so.1
7fb2551fc000-7fb2551fd000 ---p 00000000 00:00 0
7fb2551fd000-7fb2559fd000 rw-p 00000000 00:00 0
7fb2559fd000-7fb2559fe000 ---p 00000000 00:00 0
7fb2559fe000-7fb2561fe000 rw-p 00000000 00:00 0
7fb2561fe000-7fb2561ff000 ---p 00000000 00:00 0
7fb2561ff000-7fb2569ff000 rw-p 00000000 00:00 0
7fb2569ff000-7fb256a00000 ---p 00000000 00:00 0
7fb256a00000-7fb257200000 rw-p 00000000 00:00 0
7fb257200000-7fb257350000 r-xp 00000000 09:01 220815 /lib64/libc-2.11.3.so
7fb257350000-7fb257550000 ---p 00150000 09:01 220815 /lib64/libc-2.11.3.so
7fb257550000-7fb257554000 r--p 00150000 09:01 220815 /lib64/libc-2.11.3.so
7fb257554000-7fb257555000 rw-p 00154000 09:01 220815 /lib64/libc-2.11.3.so
7fb257555000-7fb25755a000 rw-p 00000000 00:00 0
7fb25755a000-7fb2575b1000 r-xp 00000000 09:01 1122129 /usr/lib64/libgmp.so.3.5.2
7fb2575b1000-7fb2577b1000 ---p 00057000 09:01 1122129 /usr/lib64/libgmp.so.3.5.2
7fb2577b1000-7fb2577b2000 r--p 00057000 09:01 1122129 /usr/lib64/libgmp.so.3.5.2
7fb2577b2000-7fb2577b3000 rw-p 00058000 09:01 1122129 /usr/lib64/libgmp.so.3.5.2
7fb2577b3000-7fb2577ca000 r-xp 00000000 09:01 220779 /lib64/libpthread-2.11.3.so
7fb2577ca000-7fb2579c9000 ---p 00017000 09:01 220779 /lib64/libpthread-2.11.3.so
7fb2579c9000-7fb2579ca000 r--p 00016000 09:01 220779 /lib64/libpthread-2.11.3.so
7fb2579ca000-7fb2579cb000 rw-p 00017000 09:01 220779 /lib64/libpthread-2.11.3.so
7fb2579cb000-7fb2579cf000 rw-p 00000000 00:00 0
7fb2579cf000-7fb2579ed000 r-xp 00000000 09:01 220814 /lib64/ld-2.11.3.so
7fb257bad000-7fb257bb1000 rw-p 00000000 00:00 0
7fb257bea000-7fb257bec000 rw-p 00000000 00:00 0
7fb257bec000-7fb257bed000 r--p 0001d000 09:01 220814 /lib64/ld-2.11.3.so
7fb257bed000-7fb257bee000 rw-p 0001e000 09:01 220814 /lib64/ld-2.11.3.so
7fb257bee000-7fb257bef000 rw-p 00000000 00:00 0
7fff43092000-7fff430b3000 rw-p 00000000 00:00 0 [stack]
7fff4311f000-7fff43120000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Non so da che dipenda. Ultimamente ho solo aggiornato il kernel alla versione 2.6.37-r1. E comunque il programma sembra che giri correttamente!

Io quell'output non lo capisco. Qualcuno mi aiuta per favore?

WarDuck
11-03-2011, 18:27
L'errore è questo: double free or corruption.

Questo accade in genere quando si chiama 2 volte free su un puntatore che indirizza un'area di memoria oppure quando c'è corruzione nell'area di memoria (magari fai scritture che non dovresti fare).

Usa il tool valgrind per scoprire quali sono i problemi di gestione della memoria che ha il tuo programma.

Se il tool non segnala alcun errore e tutti i memory leaks sono risolti allora il problema dev'essere un altro.

fbcyborg
11-03-2011, 19:47
Ciao WarDuck, grazie infinite per la risposta. Ammetto che ora che mi ci fai pensare, quel double free avrebbe dovuto farmi capire che fosse qualche free sbagliata. Però non sono una cima in C, purtroppo!

Commentando le free incriminate infatti il problema sparisce.

Dunque, senza usare Valgrind, sono riuscito a isolare il problema. In pratica sono delle free apposite che mette a disposizione la libreria libpaillier (http://acsc.cs.utexas.edu/libpaillier/), che io lancio per liberare la memoria, ovvero:
void *free_plaintext(paillier_plaintext_t **decrypted, int len){
int i;
for(i=0;i<len;i++){
paillier_freeplaintext(decrypted[i]);
}
}

void *free_ciphertext(paillier_ciphertext_t **encrypted, int len){
int i;
for(i=0;i<len;i++){
paillier_freeciphertext(encrypted[i]);
}
}

E le chiamo dall'esterno con:
free_plaintext(plain,block_st.num_of_blocks);
free_ciphertext(encrypted,block_st.num_of_blocks);
free_plaintext(decrypted,block_st.num_of_blocks);
Ora mi rendo conto che non sia immediato capire cosa sto facendo da queste poche righe, ma il concetto è che sto liberando array di paillier_ciphertext_t e paillier_plaintext_t. E quindi devo fare un'operazione iterativa. Quello che non mi spiego è il perché del fatto che prima me lo faceva molto saltuariamente ed ora succede sempre.

Nella documentazione quelle funzioni sono definite così:
void paillier_freeplaintext( paillier_plaintext_t* pt );
void paillier_freeciphertext( paillier_ciphertext_t* ct );

Le variabili le dichiaro all'inizio con:
paillier_plaintext_t *plain[block_st.num_of_blocks];
paillier_ciphertext_t *encrypted[block_st.num_of_blocks];
paillier_plaintext_t *decrypted[block_st.num_of_blocks];

Immagino già una tua precisazione per farmi notare un errore, però ora non mi pronuncio, magari dico cavolate.

Grazie ancora.

fbcyborg
12-03-2011, 16:35
Succede una cosa incredibile. Sul mio portatile, un dual core, questo problema non si presenta mai! È vero che questo software è multithread ma non per quanto riguarda le varie free che menzionavo anche prima.

WarDuck
12-03-2011, 18:29
Ribadisco che secondo me ti conviene analizzare il software con valgrind, dato che è l'unico modo "accessibile" per capire cosa c'è che non va.

Inoltre con esso puoi capire meglio se è un problema del tuo programma oppure delle librerie che stai usando.

Se fossero queste ultime e se queste fossero di terza parte, ti consiglierei di contattare lo sviluppatore.

I problemi relativi alla gestione della memoria sono molto insidiosi.

fbcyborg
12-03-2011, 19:31
Ok, ti ringrazio. Ora farò qualche prova.

fbcyborg
22-03-2011, 17:38
Ciao,

dunque eccomi di nuovo; ho usato valgrind come mi hai suggerito, e l'ho fatto anche su altri software, ma vorrei concentrarmi su questo per il momento, che riguarda il pezzo di codice in cui faccio delle free.
Dunque, qualcosa intuisco ma non è proprio semplice per me, visto che lo sto usando solo da un'ora, però ecco quanto (http://pastebin.com/3vELRp1W) sputa fuori.
Ovviamente quando lancio valgrind tutto quel Memory map di prima non lo sputa fuori.

fbcyborg
25-03-2011, 14:08
Alla fine poi ho risolto.
C'era un problema di malloc da un'altra parte nel codice, e risolto quello si è risolto anche questo problema.

Grazie comunque.

WarDuck
25-03-2011, 14:25
Scusami ho visto solo ora, valgrind ti da un'idea di massima di dove andare a cercare il problema (in pratica vedi quali sono le funzioni in cui sono presenti eventuali errori e cerchi di capire dove sia il problema).
Tra l'altro dal log si evince che ci sono dei memory leaks, ovvero fai delle malloc ma non liberi la memoria alla fine...

Comunque bene che tu abbia risolto, è bene controllare sempre con valgrind che non ci siano errori, così sei ragionevolmente sicuro che il tuo programma non ha problemi di gestione della memoria, e ciò significa avere un programma molto più stabile.

fbcyborg
25-03-2011, 14:28
Ottimo! :)

Grazie ancora!!