Tutorial Valgrind

1. Introducere

Cui i se adreseaza acest tutorial ?
Oricui isi propune sa scrie aplicatii C/C++ ruland pe sisteme Linux.

Ce este Valgrind ?
Valgrind este o suita de programe utilitare, putand fi folosit pentru depanarea problemelor privind utilizarea memoriei, detectarea memory leak-urilor si pentru profiling.

Cum functioneaza ?
Valgrind este, in esenta, o masina virtuala. Atunci cand executam un program folosind Valgrind, acesta este rulat in respectiva masina virtuala. Cu aceasta ocazie, sunt aplicate anumite tehnici si procedee de instrumentare a codului care permit detectia unor categorii de erori de programare.
Valgrind ruleaza doar pe platforme Linux.
Exista programe similare si pentru utilizatorii Windows, dar, de obicei, sunt comerciale. Dintre alternativele valabile pe sisteme Windows, putem enumera: IBM Purify, Parasoft Insure++, etc.

Care sunt categoriile de erori pe care le poate detecta Valgrind ?
Valgrind consta dintr-o suita de programe utilitare.
Proababil cel mai utilizat dintre ele este memcheck, destinat analizei utilizarii memoriei.

Acesta poate detecta erori precum:
- Utilizarea memoriei neinitializate
- Accesarea memoriei dezalocate
- Buffer overflows, pentru buffer-ele alocate pe heap
- Anumite cazuri de accesare incorecta a memoriei pe stiva curenta
- Memory leaks
- Utilizarea incorecta a functiilor de alocare/dezalocare a memoriei

In afara de memcheck, mai exista:
- Callgrind -> util pentru generarea de callgraph-uri (pentru profiling)
- Cachegrind -> util pentru profiling privind utilizarea cache-urilor
- Massif -> util pentru profiling privind utilizarea memoriei alocate dinamic
- Helgrind -> detecteaza greseli tipice in utilizarea thread-urilor POSIX

Cum il instalam ?
Este disponibil aici: http://valgrind.org/
Pe sistemele Debian (sau derivate din Debian, precum Ubuntu), se poate instala executand:

2. Utilizare

2.1. Detectia utilizarii memoriei neinitializate

Avem urmatorul cod (uninit_memory.c):


Il compilam:


Ruland folosind utilitarul memcheck:

obtinem:

Precum se poate observa, Valgrind raporteaza o eroare la linia 8 (if (i == 0)), privind utilizarea unei variabile neinitializate.

Detectia functioneaza si in cazul unui array alocat pe stiva (uninit_array.c).


Compilare:

Executand folosind memcheck:

obtinem:

Valgrind raporteaza o eroare la linia if (strcmp(name, "root")), pentru ca array-ul name se foloseste neinitializat.

Sa vedem daca Valgrind detecteaza acest tip de eroare si in cazul utilizarii unui array alocat dinamic (pe heap).
Avem urmatorul cod sursa (uninit_dynamic_array.c):

Compilare:

Executand folosind memcheck:

obtinem

Valgrind continua sa detecteze problema.
Precum se poate observa, fata de situatiile anterioare, am utilizat in plus optiunea --leak-check=yes, pentru a detecta posibilele erori de tip memory leak (pentru ca acum alocam dinamic memorie). In cazul programului de mai sus, nu avem astfel de erori.

2.2. Detectia acceselor la memoria dezalocata

Avem urmatorul cod sursa (deallocated_memory_access.c):

In acest program, se acceseaza memorie dezalocata la urmatoarea linie: *p = 2.

Compilare:

Executand folosind memcheck:

obtinem:


Mesajul oferit de catre Valgrind ne spune urmatoarele lucruri:

- s-a facut un acces invalid la memorie, in mod scriere, pe 4 octeti (dimensiunea tipului int, pe sistemul meu)
- accesul s-a facut la linia 9 in fisierul deallocated_memory_access.c
- adresa la care s-a incercat scrierea a fost 0x41b1028. Aceasta adresa este localizata intr-un bloc de memorie alocat dinamic, de dimensiune 4 octeti (iarasi egal cu dimensiunea int-ului pe sistemul meu), dar care a fost in prealabil dezalocat, la linia 7, in fisierul deallocated_memory_access.c

Utilizatorii limbajului C++ se pot intreba daca detectia functioneaza si in cazul in care memoria este alocata folosind operatorul new si dezalocata folosind operatorul delete.
Avem urmatorul cod C++ (deallocated_memory_access.cpp)

Compilare:

Executand folosind memcheck:

obtinem:

Precum se poate observa, detectia a fost efectuata si in acest caz.

In continuare, dorim sa vedem daca detectia functioneaza si in cazul unui array, alocat folosind operatorul new[], dezalocat folosind operatorul delete [], apoi accesat (deallocated_array_access.cpp)

Compilare:

Executand folosind memcheck:

obtinem:

Acest mesaj ne spune urmatoarele lucruri:

- se face un acces invalid la memorie, in mod citire (read), pe 4 octeti
- accesul se face la linia 12, in fisierul deallocated_array_access.cpp (adica la linia std::cout << array[i] << "\n";)
- adresa accesata in mod incorect este 0x42d6028, aflandu-se intr-un block de memorie avand dimensiunea de 40 de octeti, alocat dinamic dar dezalocat in prealabil
- blocul de memorie a fost dezalocat la linia 9, in fisierul deallocated_array_access.cpp (adica delete [] array;)

2.3. Detectia problemelor de tip "memory leak"

Pentru cei nefamiliarizati cu termenul, aceast gen de probleme se refera la situatiile in care un program aloca dinamic memorie, dar nu o mai dezaloca.
Valgrind este un utilitar foarte bun in gasirea acestor tipuri de probleme. Exista si alte utilitare ce pot fi folosite, pe sisteme, Linux, pentru detectia acestor situatii (de exemplu mpatrol).

Urmatorul cod (memory_leaks.cpp) expune acest tip de problema.

Compilare:

Executand folosind memcheck:

obtinem:


Observam faptul ca Valgrind raporteaza locatiile in care s-au facut alocari de memorie care au dus la memory leaks (pentru care nu au existat dezalocari):

-> Linia 8: int *c_p = (int *)std::malloc(sizeof(int));
S-au alocat 4 octeti, folosind functia malloc, si nu au mai fost dezalocati

-> Linia 10: int *c_q = (int *)std::malloc(10 * sizeof(int));
S-au alocat 10 x 4 = 40 de octeti, folosind functia malloc, si nu au mai fost dezalocati

->Linia 18: int *cpp_p = new int;
S-au alocat 4 octeti, folosind operatorul new, si nu au mai fost dezalocati

->Linia 20: int *cpp_q = new int[10];
S-au alocat 10 x 4 = 40 de octeti, folosind operatorul new[], si nu au mai fost dezalocati

Avem un memory leak de: 4 + 40 + 4 + 40 = 88 de octeti, lucru specificat si in sectiunea LEAK SUMMARY a raportului oferit de catre Valgrind

Haideti sa rezolvam problemele raportate de catre Valgrind, sa rulam din nou utilitarul si sa vedem cum arata noul raport.
Noul fisier sursa este no_memory_leaks.cpp:

Compilare:

Executand folosind memcheck:

obtinem:

Precum se poate observa, Valgrind nu mai raporteaza nici o problema de tip memory leak.

2.4. Utilizarea incorecta a functiilor de alocare/dezalocare a memoriei

O problema destul de frecvent intalnita de catre programatorii C++ incepatori este utilizarea operatorului delete in locul operatorului delete [], pentru a dezaloca un array alocat dinamic.
Haideti sa vedem daca Valgrind detecteaza aceasta situatie (array_delete_missuse.cpp):

Compilare:

Executand folosind memcheck:

obtinem:

Precum se poate observa, Valgrind raporteaza faptul ca s-a incercat eliberarea memoriei intr-un mod incorect, la linia 15 (delete p;), in fisierul array_delete_missuse.cpp

In general, regulile care trebuiesc urmate in privinta dezalocarii memoriei, in C++, sunt urmatoarele:

- memoria alocata folosind functiile malloc()/calloc()/realloc() trebuie sa fie dezalocata folosind functia free()
- memoria alocata folosind operatorul new trebuie dezalocata folosind operatorul delete
- memoria alocata folosind operatorul new [] trebuie dezalocata folosind operatorul delete []

Valgrind va detecta situatiile in care aceasta regula este incalcata (de exemplu in cazul in care se aloca memorie folosind functia malloc(), dar se dezaloca folosind operatorul delete).

O alta posibila problema este incercarea de a dezaloca o zona de memorie care nu a fost alocata dinamic.
Exemplul urmator (invalid_dealloc.c) demonstreaza acest tip de problema.

Compilare:

Executand folosind memcheck:

obtinem:

Mesajul ne spune faptul ca, la linia 17 in fisierul invalid_dealloc.c, am incercat sa dezalocam o zona de memorie alocata pe stiva.

De asemenea, Valgrind este capabil sa detecteze probleme de tip double-free (in care o zona de memorie alocata dinamic este dezalocata de doua sau mai multe ori).
Exemplul urmator demonstreaza acest lucru (double_free_error.c)

Compilare:

Executand folosind memcheck:

obtinem:

Analizand mesajul, se observa ca a avut loc o operatie invalida de dezalocare, utilizand functia free(), la linia 10 in fisierul double_free_error.c.

2.5. Detectia problemelor de tip buffer-overflow

Problemele de tip buffer-overflow trebuiesc tratate in modul cel mai serios. Ele preprezinta un risc de securitate major, fiind o tinta predilecta a exploit-urilor, putandu-se ajunge chiar la executia de cod arbitrar pe sistemul "victimei", cu drepturi de super-user.
Incepem cu un exemplu simplu de buffer overflow, in cazul unui buffer alocat dinamic (pe heap) (simple_buffer_overflow.c)

Compilare:


Daca rulez executabilul (fara sa folosesc Valgrind), obtin urmatorul output pe sistemul meu.


Aparent nu e nici o problema, programul nu a "crapat". Dar nu e deloc asa ... programul prezinta un buffer-overflow evident la linia array[i] = i, pentru cazul in care i = NUMBER_ELEMS. Iar daca nu a "crapat" in cazul meu, nu inseamna ca atunci cand va fi rulat din nou (eventual pe un alt sistem) nu se va intampla.
Erorile de acest gen duc la coruperea memoriei, care cauzeaza de obicei un comportament impredictibil al programului.

Sa rulam programul utilizand Valgrind:

Se obtine:

In acest moment devine evident faptul ca programul acceseaza incorect memoria (in afara buffer-ului):
- in mod scriere (la linia 13): array[i] = i;
- in mod citire (la linia 14): printf("array[%d] = %d\n", i, array[i]);
in cazul in care variabila i are valoarea 10.

Sa facem o mica modificare in codul anterior. Buffer-ul nu va mai fi alocat dinamic, ci va fi alocat pe stiva.
Rezulta urmatorul cod (stack_buffer_overflow.c):

Compilare:

Ruland folosind mcheck:

obtinem:

Precum se poate observa, Valgrind nu a raportat nici o eroare ... Asta inseamna cumva faptul ca codul nu are nici o problema ? Nu, inseamna doar faptul ca Valgrind nu a detectat overflow-ul unui buffer alocat pe stiva.
Pur si simplu Valgrind "nu stie" sa detecteze o astfel de problema.

2.6. Detectia de erori privind utilizarea thread-urilor POSIX

Utilitarul helgrind poate fi folosit pentru a detecta erori tipice privind utilizarea thread-urilor POSIX (pthreads).

2.6.1. Race-condition
In exemplul urmator (race_condition.c), vom utiliza helgrind pentru a detecta o problema de tip race-condtion.


In acest exemplu sunt create doua thread-uri: thread1 si thread2.
Cele thread-uri incrementeaza valoarea unei variabile globale, g_counter (fiecare thread incrementeaza g_counter de doua ori, intr-o bucla).
Functia sleep este folosita doar pentru a creste probabilitatea desincronizarii celor doua thread-uri.
Este evident faptul ca cele doua thread-uri sunt in race unul cu celalat, accesul la variabila globala nefiind sincronizat in nici un fel.

Compilare:


Ruland folosind helgrind:

obtinem:

Valgrind raporteaza faptul ca exista o problema de tip race-condition in fisierul race_condition.c, in functia increment_counter(), la liniile 13, 15 si 16 (adica exact acolo unde variabila globala g_counter este citita respectiv modificata).

Pentru a rezolva aceasta problema, putem folosi un mutex, pentru a asigura accesul sincronizat la variabila g_counter. Exemplul urmator ilustreaza acest lucru (no_race_condition.c):

In acest caz, Valgrind nu mai raporteaza nici o problema.

2.6.2. Deadlock
O alta problema des intalnita in dezvoltarea de aplicatii multi-threaded este situatia de deadlock.
Programul de mai jos (deadlock.c) este vulnerabil la aceasta problema.
Se observa aplicarea unuia din cazurile clasice in care se ajunge la deadlock: doua thread-uri achizitioneaza 2 lock-uri (in cazul de fata de tip mutex) in ordine invers.

Compilare:

Ruland folosind helgrind:

obtinem:

Se observa ca Valgrind a detectat situatia de deadlock, datorata faptului ca lock-urile sunt achizitionate in ordine inversa de catre cele doua thread-uri.

Foarte bun tutorialul si atinge un subiect util. Am vazut multi programatori care nu aveau habar sa foloseasca Valgrind si dupa ce au invatat memcheck-ul unul a reusit sa scada consumul de memorie al unui program de la 450 la 300 de mega... 33% e destul de mult deja...

Voiam sa recomand - pentru cei care folosesc Windows - si uneltele puse la dispozitie de Visual Studio (poate sunt unii care cauta o alternativa free pentru Windows - puteti folosi Visual Studio Express, varianta pentru C++ are suport pentru memory leak checking prin metoda descrisa aici - http://msdn.microsoft.com/en-us/library ... 80%29.aspx).

Nu sunt un avocat MS, m-am ciocnit si eu zilele trecute de nevoia de un memcheck pe windows si am gasit alternativa asta. N-am incercat-o inca (sunt inca in dezvoltarea partii care va trebui testata) dar din cate am vazut pare utila. Sper sa revin cu mai multe informatii pentru cei interesati.