TESTER CURENJA MEMORIJE V1.2 (C) Doc. dr. Zeljko Juric, 2010 Prirodno matematički fakultet, Odsjek za matematiku Sarajevo, Bosna i Hercegovina UPUTE ZA KORIŠTENJE 1. Čemu ovaj program služi? Tester curenja je jednostavan pomoćni program namijenjen za otkrivanje grešaka tipa curenja memorije (engl. memory leaks) u Vašim programima. Na tržištu već postoji veći broj programa ovog tipa, od kojih su neki komercijalni, a neki se mogu preuzeti besplatno. Mada su ozbiljni testeri memorije po mogućnostima znatno iznad ovdje ponuđenog testera, svi su oni znatno složeniji za upotrebu. Bez obzira na ograničene mogućnosti, ovaj tester sasvim dobro obavlja svoj osnovni zadatak: detekciju curenja memorije. Pored toga, on može otkriti i neke druge probleme vezane za upravljanje memorijom, poput oslobađanja već oslobođenog dijela memorije, što je greška koja često dovodi do kraha programa. U mnogim slučajevima ovaj tester može otkriti i česte početničke greške koje se sastoje u oslobađanju memorije na pogrešan način, poput oslobađanja dinamički alociranih nizova pomoću običnog operatora “delete” (umjesto pomoću “delete[]”) odnosno oslobađanja običnih objekata (koji nisu nizovi) pomoću “delete[]”.
2. Šta je curenje memorije? Curenje memorije je česta programerska greška koja se očituje u tome da program dinamički zauzme izvjesnu količinu resursa koje nigdje ne oslobađa. Logički se može razlikovati jako i slabo curenje memorije. Kod jakog curenja memorije, program ne može osloboditi zauzetu memoriju sve i da hoće, jer je pokazivač kojim se pristupa zauzetoj memoriji izgubljen, kao u sljedećem primjeru: int *a(new int[100]); ... a = new int[50];
// zauzima se blok memorije // pokazivač na prethodno zauzeti blok je izgubljen
Ovdje je nakon posljednje izvršene dodjele pokazivač na prvi alocirani blok memorije izgubljen, tako da imamo jako curenje memorije (osim ukoliko se prije dodjele zauzeti blok ne oslobodi eksplicitno). S druge strane, kod slabog curenja memorije, program prosto ne oslobađa dijelove memorije koji mu više ne trebaju, mada im i dalje ima pristup. Generalno, jako curenje memorije je mnogo ozbiljnije, posebno ukoliko do njega dolazi unutar neke petlje. U tom slučaju, što izvršavanje programa duže traje, više se memorije gubi, tako da program koji naizgled radi ispravno može otkazati poslušnost nakon nekoliko sati pa čak i mjeseci rada (recimo u programima koji nikad ne prekidaju rad poput web servera, itd.). Složeniji detektori curenja mogu detektirati jako curenje memorije istog trenutka kada do njega dođe (tj. čim zauzeta memorija postane nedostupna), dok se slabo curenje memorije ne može detektirati prije završetka programa (jer sve do kraja programa ne možemo znati da li će zauzeta memorija kojoj se može pristupiti možda zatrebati). Ovaj detektor prijavljuje sva curenja memorije (bilo slaba bilo jaka) tek po završetku programa. Detektori koji koji mogu jaka curenja memorije otkriti odmah po njihovoj pojavi mnogo su složenije strukture i obično su komplikovaniji za upotrebu.
3. Kako se koristi ovaj detektor? Za svoju osnovnu funkciju, upotreba detektora je krajnje jednostavna. Sve što trebate uraditi je smjestiti detektor (datoteku “TestCurenja.h”) u isti folder u kojem se nalazi i program koji se testira a zatim u program koji se testira trebate nakon direktiva kojima se uključuju zaglavlja standardnih biblioteka poput “cmath”, “iostream”, “string”, itd. ubaciti red koji sadrži direktivu
#include "TestCurenja.h"
Vrlo je važno da ovaj red trebate ubaciti tek nakon redova u kojima se uključuju zaglavlja standardnih biblioteka a ne prije njih. U suprotnom, program se vrlo vjerovatno neće moći kompajlirati. Treba napomenuti da je ovaj tester namijenjen za testiranje “školskih” programa kod kojih se čitav program nalazi u jednoj programskoj datoteci. Drugim riječima, tester nije namijenjen za testiranje programa – projekata, kod kojih se kôd programa nalazi razbacan u skupini povezanih datoteka. Ovo ograničenje se lako može ukloniti, s tim što se uklanjanjem tog ograničenja upotreba testera neznatno komplicira. Zainteresirani se mogu obratiti autoru za verziju testera koja omogućava testiranje i takvih kompleksnijih programskih projekata. Nakon uključenja zaglavlja “TestCurenja.h”, tester se infiltrira u program koji se testira poput virusa, preuzimajući kontrolu nad mehanizmom upravljanja memorije. Pri tome, tester vrši internu evidenciju o svakoj izvršenoj alokaciji i dealokaciji (kasnije će biti opisano kako se može generirati izvještaj o svakoj pojedinačnoj alokaciji i dealokaciji) uporedo sa normalnim radom programa koji se testira. Kada testirani program završi sa radom, tester automatski generira završni izvještaj koji sadrži podatke o broju izvršenih alokacija i dealokacija tokom rada programa, zatim ukupnoj količini memorije koja je alocirana odnosno dealocirana tokom rada programa, te maksimalnoj količini memorije koja je u nekom trenutku bila alocirana kao i količini memorije koja je ostala alocirana po završetku programa (nenulta vrijednost alocirane memorije po završetku programa ukazuje na curenje memorije). Ukoliko nije detektirano curenje memorije, ispisuje se odgovarajuća potvrda o tome. Na primjer, mogući izvještaj po završetku nekog ispravnog programa može izgledati ovako: +--------------------+ | ZAVRSNI IZVJESTAJ: | +--------------------+ Ukupan broj alokacija: 3 Ukupan broj dealokacija: 3 Ukupna kolicina izvrsenih alokacija u bajtima: 2 200 Ukupna kolicina izvrsenih dealokacija u bajtima: 2200 Maksimalno zauzece memorije tokom rada programa u bajtima: 1600 Zauzece memorije po zavrsetku programa u bajtima: 0 BRAVO! NEMA NIGDJE CURENJA MEMORIJE
Ukoliko se detektira curenje memorije, na kraju izvještaja se daje detaljan spisak koji ukazuje na mjesta gdje je alocirana memorije koja do kraja programa nije osobođena. Na primjer, razmotrimo sljedeći program u kojem je namjerno napravljeno nekoliko curenja memorije (od kojih su neka jaka, poput onih izazvanih nepropisnom alokacijom unutar tijela petlje): #include
using namespace std; int main() { int *a(new int[100]); int *b(new int(5)); for(int i = 0; i < 5; i++) b = new int(10); delete b; a = new int[300]; new int(5); b = new int[200]; delete[] a; return 0; }
Nakon što aktiviramo detektor (uključivanjem zaglavlja “TestCurenja.h”), po završetku programa dobićemo izvještaj poput sljedećeg (pri čemu se tačne vrijednosti dopunskih informacija koje se prikazuju mogu razlikovati od slučaja do slučaja): +--------------------+ | ZAVRSNI IZVJESTAJ: | +--------------------+ Ukupan broj alokacija: 10 Ukupan broj dealokacija: 2 Ukupna kolicina izvrsenih alokacija u bajtima: 2 428 Ukupna kolicina izvrsenih dealokacija u bajtima: 1204 Maksimalno zauzece memorije tokom rada programa u bajtima: 2424 Zauzece memorije po zavrsetku programa u bajtima: 1224 NE -
VALJA! Adresa Adresa Adresa Adresa Adresa Adresa Adresa Adresa
IMATE CURENJA MEMORIJE NA SLJEDECIM MJESTIMA: 003D3D08, 800 bajta, alocirano u 14. liniji programa 003D2798, 4 bajta, alocirano u 13. liniji programa 003D2768, 4 bajta, alocirano u 10. liniji programa 003D2738, 4 bajta, alocirano u 10. liniji programa 003D2708, 4 bajta, alocirano u 10. liniji programa 003D26D8, 4 bajta, alocirano u 10. liniji programa 003D2498, 4 bajta, alocirano u 8. liniji programa 003D2500, 400 bajta, alocirano u 7. liniji programa
Analizom izvještaja lako uviđamo šta se zaista dešava. Značajna je stvar što se ispisuju brojevi linija programa u kojima su izvršene sporne alokacije, što mnogi testeri ne podržavaju (za uvo đenje ove mogućnosti je ipak plaćena izvjesna cijena, o čemu će biti riječi kasnije). Prethodni primjer bio je vještački konstruisan. Sljedeći realističniji primjer upotrebe testera curenja ilustrira neke detaje na koje je bitno obratiti pažnju: #include #include "TestCurenja.h" using namespace std; double f(double x) { if(x == 0) throw "Dijeljenje nulom!\n"; return 1 / x; } double g(int p, int q) { double *a(new double[p]); a[0] = p; a[1] = q; for(int i = 2; i < p; i++) a[i] = a[i - 2] - a[i - 1]; for(int i = 0; i < p; i++) a[i] = f(a[i]); double s(0); for(int i = 0; i < p; i++) s += i * a[i]; delete[] a; return s; } int main() { try { cout << g(8, 5); } catch(const char poruka[]) { cout << poruka; } return 0; }
U ovom programu funkcija “g” obavlja nekakav račun (nebitno kakav) za koji joj je potreban niz od “p” realnih brojeva. Za tu svrhu je dinamički alociran niz kojem se pristupa preko pokazivača “a”. Naizgled je sve dobro, jer programer oslobađa alocirani prostor na kraju funkcije “g”. Međutim, programer je previdio mogućnost da funkcija “g” bude nasilno prekinuta ranije zbog bacanja izuzetka iz funkcije “f”. Upravo se to i dešava u ovom testnom primjeru za ulazne podatke 8 i 5. Zbog toga ćemo, po završetku programa, dobiti izvještaj poput sljedećeg: +--------------------+ | ZAVRSNI IZVJESTAJ: | +--------------------+ Ukupan broj alokacija: 1 Ukupan broj dealokacija: 0 Ukupna kolicina izvrsenih alokacija u bajtima: 4 0 Ukupna kolicina izvrsenih dealokacija u bajtima: 0 Maksimalno zauzece memorije tokom rada programa u bajtima: 40 Zauzece memorije po zavrsetku programa u bajtima: 40 NE VALJA! IMATE CURENJA MEMORIJE NA SLJEDECIM MJESTIMA: - Adresa 003D2500, 40 bajta, alocirano u 12. liniji programa
Rješenje je jednostavno: izuzetak treba hvatati u funkciji “g”. U slučaju da se uhvati izuzetak, treba osloboditi memoriju i proslijediti izuzetak dalje: double g(int p, int q) { double *a(new double[p]); try { a[0] = p; a[1] = q; for(int i = 2; i < p; i++) a[i] = a[i - 2] - a[i - 1]; for(int i = 0; i < p; i++) a[i] = f(a[i]); double s(0); for(int i = 0; i < p; i++) s += i * a[i]; delete[] a; return s; } catch(...) { delete[] a; throw; } }
Naravno, još je jednostavnije koristiti tip “vector” koji se o takvim stvarima brine automatski (pouka: koristite vektore umjesto dinamičke alokacije nizova kad god to možete). Vratimo se nazad na nemodifikovani primjer. Ukoliko bismo u glavnom programu poziv “g(8, 5)” zamijenili sa pozivom “g(7, 5)”, dobili bismo izvještaj da curenja memorije nema. I zaista ga u tom slučaju nema, jer izuzetak neće biti bačen. Ovaj primjer ilustrira važnu osobinu svih postojećih testera curenja memorije (uključujući i ovaj): svi testeri curenja memorije mogu detektovati curenje memorije samo ako do njega zaista dođ e tokom izvršavanja programa. Niti jedan tester memorije ne može logički analizirati program i ustanoviti da li u njemu može doći do curenja memorije pod određenim uvjetima ili ne, nego samo može reći da li je tokom konkretnog izvršavanja programa detektovano curenje ili ne. Stoga je veliki problem detektirati curenja memorije do kojih dolazi rijetko, samo u nekim vrlo specifičnim okolnostima. To je ujedno i razlog zbog kojeg i brojni komercijalni programi pate od problema sa curenjem memorije, bez obzira na brojne raspoložive testere. Nažalost, u teoriji računarstva se pokazuje da je u općem slučaju problem određivanja da li u programu postoji mogućnost curenja memorije ili ne algoritamski nerješiv (za upućenije, on je logički ekvivalentan halting problemu). To zapravo znači da se ne može očekivati da će ikada biti napravljen tester koji će za svaki program logičkom analizom moći zaključiti postoji li u njemu mogućnost curenja memorije ili ne.
4. Prikazivanje izvršenih alokacija i dealokacija U nekim slučajevima programeru može biti od koristi da na ekranu dobije obavijest (notifikaciju) svaki put kada se izvrši neka alokacija ili dealokacija (oslobađanje). Ova mogućnost se može aktivirati izvršavanjem naredbe UKLJUCI_OBAVJESTAVANJE;
Obavještavanje započinje od trenutka izvršavanja ove naredbe pa sve do kraja programa, ili dok se ne naiđe na naredbu ISKLJUCI_OBAVJESTAVANJE;
U istom programu može se proizvoljan broj puta uključivati i isključivati obavještavanje, zavisno koji dio programa programer želi nadzirati. Slijedi jednostavan primjer upotrebe: #include #include "TestCurenja.h" using namespace std; int main() { UKLJUCI_OBAVJESTAVANJE; int *a(new int[100]); int *b(new int(5)); for(int i = 0; i < 5; i++) { cout << "i = " << i << endl; b = new int(10); } delete b; a = new int[300]; new int(5); b = new int[200]; delete[] a; return 0; }
Tokom rada programa na ekranu će se generirati ispis poput sljedećeg >>> >>> i = >>> i = >>> i = >>> i = >>> i = >>> >>> >>> >>> >>> >>>
U 8. liniji programa alocira se 400 bajta na adresi 003D2500 U 9. liniji programa alocira se 4 b ajta na adresi 003D2498 0 U 12. liniji programa alocira se 4 bajta na adresi 003D26D8 1 U 12. liniji programa alocira se 4 bajta na adresi 003D2708 2 U 12. liniji programa alocira se 4 bajta na adresi 003D2738 3 U 12. liniji programa alocira se 4 bajta na adresi 003D2768 4 U 12. liniji programa alocira se 4 bajta na adresi 003D2798 Oslobadja se 4 bajta na adresi 003D2798 U 15. liniji programa alocira se 1200 bajta na adresi 003D4858 U 16. liniji programa alocira se 4 bajta na adresi 003D2798 U 17. liniji programa alocira se 800 bajta na adresi 003D4D10 Oslobadja se 1200 bajta na adresi 003D4858
Ispis promjenljive “i” unutar petlje je ubačen čisto da bi program i sam po sebi nešto ispisivao tokom rada, da uočite kako se obavještenja koja generira tester miješaju sa ispisom koji generira program sam po sebi. Po završetku programa dobija se i završni izvještaj poput sljedećeg:
+--------------------+ | ZAVRSNI IZVJESTAJ: | +--------------------+ Ukupan broj alokacija: 10 Ukupan broj dealokacija: 2 Ukupna kolicina izvrsenih alokacija u bajtima: 2 428 Ukupna kolicina izvrsenih dealokacija u bajtima: 1204 Maksimalno zauzece memorije tokom rada programa u bajtima: 2424 Zauzece memorije po zavrsetku programa u bajtima: 1224 NE -
VALJA! Adresa Adresa Adresa Adresa Adresa Adresa Adresa Adresa
IMATE CURENJA MEMORIJE NA SLJEDECIM MJESTIMA: 003D4D10, 800 bajta, alocirano u 15. liniji programa 003D2798, 4 bajta, alocirano u 14. liniji programa 003D2768, 4 bajta, alocirano u 11. liniji programa 003D2738, 4 bajta, alocirano u 11. liniji programa 003D2708, 4 bajta, alocirano u 11. liniji programa 003D26D8, 4 bajta, alocirano u 11. liniji programa 003D2498, 4 bajta, alocirano u 9. liniji programa 003D2500, 400 bajta, alocirano u 8. liniji programa
Prikazom obavještenja o svakoj izvršenoj alokaciji odnosno dealokaciji programer dobija bolji uvid u to šta se zaista dešava pri izvršavanju programa i može bolje identificirati zašto mu curi memorija. Primijetimo da iako obavijest o izvršenoj alokaciji sadrži informaciju o rednom broju linije programa u kojoj je alokacija izvršena, kod obavijesti o dealokacijama ta informacija nažalost nije prisutna. Međutim, takvu informaciju je izuzetno teško izvući bez saradnje sa samim kompajlerom, a autorova namjera nije da modificira sam kompajler i na kakav način. S druge strane, ponuđena je informacija o adresi dijela memorije koji se oslobađa, tako da je lako povezati koja na koju se alokaciju odnosi razmatrana dealokacija.
4. Problematika internih alokacija Izvjesne funkcije iz standardne biblioteke jezika C++ koriste dinamičku alokaciju memorije za svoje interne potrebe. Također rad nekih tipova podataka iz standardne biblioteke interno se zasniva na dinamičkoj alokaciji memorije (to se recimo odnosi na objekte tipa “vector”, “string” itd.). Naravno, tako zauzeta memorija se automatski oslobađa kada više nije potrebna, o čemu se brinu implementacije odgovarajućih funkcija odnosno tipova podataka. Autor ovog testera je dugo vremena bio u dilemi da li da obavještava korisnika o internim alokacijama i dealokacijama. Izgledalo je da to nije potrebno, već da samo nepotrebno zbunjuje korisnika. Međutim, detaljnije testiranje je pokazalo da curenje memorije može indirektno biti izazvano č ak i internim alokacijama i to ne zbog baga u izvedbi funkcija i tipova podataka u standardnoj biblioteci, već zbog nepažnje programera. Zbog toga ovaj tester obavještava korisnika i o internim alokacijama i dealokacijama. Prije nego što razmotrimo primjer koji pokazuje kako interne alokacije mogu dovesti do curenja memorije, razmotrimo prvo sljedeći primjer koji demonstrira šta su uopće interne alokacije: #include #include #include "TestCurenja.h" using namespace std; int main() { string s("ABC"); cout << "String s glasi " << s << endl; s = "QWERTYUIOPASDFGHJKLYXCVBNM"; cout << "A sada string s glasi " << s << endl; return 0; }
Po završetku ovog programa, pojaviće se izvještaj poput sljedećeg: +--------------------+ | ZAVRSNI IZVJESTAJ: | +--------------------+ Ukupan broj alokacija: 2 Ukupan broj dealokacija: 2 Ukupna kolicina izvrsenih alokacija u bajtima: 5 5 Ukupna kolicina izvrsenih dealokacija u bajtima: 55 Maksimalno zauzece memorije tokom rada programa u bajtima: 55 Zauzece memorije po zavrsetku programa u bajtima: 0 BRAVO! NEMA NIGDJE CURENJA MEMORIJE
Curenja memorije zaista nema, ali je tester detektirao dvije alokacije i dvije dealokacije. Gdje se one nalaze? Da bismo uvidjeli to, dodaćemo naredbu UKLJUCI_OBAVJESTAVANJE;
odmah na početak “main” funkcije, prije deklaracije stringa “s”. Pokrenemo li program, tokom njegovog izvršavanja na ekranu će se generirati ispis poput sljedećeg: >>> Interno se alocira 16 bajta na adresi 003D2500 String s glasi ABC >>> Interno se alocira 39 bajta na adresi 003D2538 >>> Oslobadja se 16 bajta na adresi 003D2500 A sada string s glasi QWERTYUIOPASDFGHJKLYXCVBNM >>> Oslobadja se 39 bajta na adresi 003D2538
Šta se dešava? Pri deklaraciji stringa “s” (9. linija programa) zauzima se prostor u memoriji za pamćenje sadržaja stringa (znakova “ABC”) i za neke režijske potrebe. Ta alokacija se obavlja interno unutar same implementacije tipa “string” u istoimenoj biblioteci. U 11. liniji programa stringu “ s” dodjeljuje se vrijednost koja je preduga da stane u zauzeti memorijski prostor. Zbog toga se vrši zauzimanje novog memorijskog prostora uz oslobađanje prethodno zauzetog memorijskog prostora. Po završetku programa vrši se automatsko oslobađanje zauzete memorije, o čemu programer ne mora da brine. Primijetimo da se sve interne alokacije odnosno dealokacije dešavaju unutar implementacije tipa “string” (tj. izvan dijela programa koji smo mi pisali), tako da tester nema na čina da sazna koje su naredbe u našem programu pokrenule te mehanizme (radi se o naredbama u 9. i 11. liniji programa). Bilo bi korisno kada bi tester umjesto neinformativnog komentara “Interno se alocira” mogao reći da je do te alokacije zapravo posredno došlo u 9. odnosno 11. liniji programa, ali tu informaciju tester ne može dobiti bez prepravke samog kompajlera ili standardne biblioteke. Pokažimo sada kako interne alokacije mogu dovesti do curenja memorije. Posmatrajmo varijantu prethodnog programa u kojem se string alocira dinamič ki, nakon čega mu se pristupa preko pokazivača “pok_s”: #include #include #include "TestCurenja.h" using namespace std; int main() { string *pok_s(new string("ABC")); cout << "String s glasi " << *pok_s << endl; *pok_s = "QWERTYUIOPASDFGHJKLYXCVBNM"; cout << "A sada string s glasi " << *pok_s << endl; return 0; }
Može se primijetiti da je programer zaboravio navesti naredbu “delete pok_s”, tako da možemo očekivati curenje memorije. Međutim, završni izvještaj je pomalo iznenađujući, jer ukazuje na curenje memorije na dva mjesta, od kojih je jedno interno: +--------------------+ | ZAVRSNI IZVJESTAJ: | +--------------------+ Ukupan broj alokacija: 3 Ukupan broj dealokacija: 1 Ukupna kolicina izvrsenih alokacija u bajtima: 5 9 Ukupna kolicina izvrsenih dealokacija u bajtima: 16 Maksimalno zauzece memorije tokom rada programa u bajtima: 59 Zauzece memorije po zavrsetku programa u bajtima: 43 NE VALJA! IMATE CURENJA MEMORIJE NA SLJEDECIM MJESTIMA: - Adresa 003D2558, 39 bajta, interno alocirano - Adresa 003D2498, 4 bajta, alocirano u 8. liniji programa
Jasno je šta smo alocirali u 8. liniji programa (tamo smo imali operator “new”), ali kakvo je curenje memorije izazvano internom alokacijom? Da bismo vidjeli šta se dešava, uključimo obavještavanje o alokacijama i dealokacijama. Tada će se tokom rada programa generirati prikaz poput sljedećeg: >>> U 9. liniji programa alocira se 4 b ajta na adresi 003D2498 >>> Interno se alocira 16 bajta na adresi 003D2520 String s glasi ABC >>> Interno se alocira 39 bajta na adresi 003D2558 >>> Oslobadja se 16 bajta na adresi 003D2520 A sada string s glasi QWERTYUIOPASDFGHJKLYXCVBNM
U 9. liniji programa se dinamički zauzima objekat tipa “string”. Inicijalno objekat tipa “string” zauzima samo 4 bajta, jer interno sadrži samo pokazivač na dio memorije gdje se nalazi njegov stvarni sadržaj i ostale informacije vezane za njegov rad (ovi detalji mogu varirati ovisno od konkretnog kompajlera i konkretne implementacije biblioteke “string”). Pri pokušaju da se string inicijalizira na vrijednost “ABC” interno se zauzima memorija za prihvat tog sadržaja. Kasnije, kada stringu dodjeljujemo duži sadržaj, zauzeta memorija ne nedovoljna, te se zauzima novi prostor a oslobađa prethodno zauzeti (isto kao u prethodnom primjeru). Međutim, kako se na kraju ne oslobađa objekat na koji pokazuje pokazivač “ pok_s”, ne oslobađa se niti sam objekat (alociran u liniji 9.) niti prostor koji je interno zauzeo objekat za čuvanje svog sadržaja. Na taj način imamo curenje memorije koje je proizašlo iz interne alokacije. Dodamo li nedostajuću naredbu “delete pok_s”, izvještaj tokom rada programa će izgledati poput sljedećeg: >>> U 9. liniji programa alocira se 4 b ajta na adresi 003D2498 >>> Interno se alocira 16 bajta na adresi 003D2520 String s glasi ABC >>> Interno se alocira 39 bajta na adresi 003D2558 >>> Oslobadja se 16 bajta na adresi 003D2520 A sada string s glasi QWERTYUIOPASDFGHJKLYXCVBNM >>> Oslobadja se 39 bajta na adresi 003D2558 >>> Oslobadja se 4 bajta na adresi 003D2498
Vidimo da je naredba “delete pok_s” oslobodila ne samo sam objekat na koji pokazivač “ pok_s” pokazuje, nego i sve resurse koje je taj objekat interno alocirao (za upućene, to se implementira pomoću tzv. destruktora). Međutim, ne oslobodimo li objekat, neće se osloboditi ni resursi interno zauzeti tokom rada objekta. Možemo se lako uvjeriti da dodavanje naredbe “delete pok_s” rješava problem. Naime, nakon dodavanja ove naredbe, završni izvještaj će izgledati poput sljedećeg:
+--------------------+ | ZAVRSNI IZVJESTAJ: | +--------------------+ Ukupan broj alokacija: 3 Ukupan broj dealokacija: 3 Ukupna kolicina izvrsenih alokacija u bajtima: 5 9 Ukupna kolicina izvrsenih dealokacija u bajtima: 59 Maksimalno zauzece memorije tokom rada programa u bajtima: 59 Zauzece memorije po zavrsetku programa u bajtima: 0 BRAVO! NEMA NIGDJE CURENJA MEMORIJE
Možemo izvesti sljedeći zaključak. Interne alokacije mogu dovesti do curenja memorije ukoliko su te alokacije posljedice rada nekog objekta koji je dinamički alociran, a nije oslobođen nakon što nije više potreban. Naime, dok se ne oslobodi sam objekat, neće se osloboditi ni dodatni memorijski resursi koje je on za vrijeme svog života zauzeo. Greške ovog tipa naročito se često javljaju kod pravljenja kontejnerskih tipova podataka, tj. tipova podataka koji interno sadrže kolekcije drugih objekata (poput povezanih listi itd.), pogotovo kada se u njih kao elementi stavljaju kompleksniji objekti čiji se rad zasniva na dinamičkoj alokaciji memorije (poput tipa “string”). Opisane pojave su razlog zbog kojeg ovaj tester obavještava programera i o internim alokacijama i dealokacijama. S druge strane, to može strahovito da nervira, jer se interne alokacije i dealokacije nekada dešavaju zaista kada malo ko to očekuje. Recimo, kompajleri zasnovani na GNU C porodici kompajlera (što uključuje i razvojna okruženja poput DevCpp-a, CodeBlocks-a itd.) interno dinamički alociraju i ubrzo oslobađaju memoriju svaki put kada se sa tastature unosi realni broj kao i kada se realni broj ispisuje na ekran (izgleda da im je izvjesna količina memorije potrebna za konverziju niza znakova unesenih sa tastature u binarni zapis realnog broja u memoriji i obrnuto). To se može vidjeti iz sljedećeg primjera koji naizgled nema nikakve veze sa dinamičkom alokacijom memorije: #include #include "TestCurenja.h" using namespace std;
int main() { UKLJUCI_OBAVJESTAVANJE; double a, b; cout << "Unesi jedan broj: "; cin >> a; cout << "Unesi drugi broj: "; cin >> b; cout << "Njihov zbir je " << a + b; return 0; }
Tokom rada programa, generira se prikaz poput sljedećeg: Unesi jedan broj: 3 >>> Interno se alocira 45 bajta na adresi 003D2500 >>> Oslobadja se 45 bajta na adresi 003D2500 Unesi drugi broj: 5 >>> Interno se alocira 45 bajta na adresi 003D2500 >>> Oslobadja se 45 bajta na adresi 003D2500 Njihov zbir je >>> Interno se alocira 2 bajta na adresi 003D2498 >>> Oslobadja se 2 bajta na adresi 003D2498 8
Mora se priznati da ovo zaista nervira. Zbog tog razloga, autor testera je razmišljao o tome da uopće ne obavještava programera o internim alokacijama. Međutim, ranije prikazani primjeri ukazuju da je to
ipak potrebno. Zbog toga, kao polurješenje ostaje mogućnost da programer privremeno isključi prikazivanje alokacija i dealokacija u onim dijelovima programa u kojima primijeti da dolazi do nervirajućeg bespotrebnog prikazivanja raznih internih alokacija i dealokacija čije postojanje programeru ne ukazuje ni našta korisno.
5. Oslobađanje već oslobođenog prostora ili prostora koji uopće nije zauzet Pored curenja memorije, najčešća greška pri upravljanju memorijom je oslobađanje već oslobođenog prostora, ili prostora koji uopće nije ni bio zauzet (ovo je poznato kao greška dvostrukog oslobađ anja odnosno engl. double free error ). Za razliku od curenja memorije koje nema fatalne posljedice sve dok ima raspoložive memorije, ova greška može imati katastrofalne posljedice. Ukoliko odmah dođe do kraha programa, možemo još reći da smo imali sreće (gora varijanta je da recimo mehanizam upravljanja memorijom bude upropašten pa da se posljedice očituju tek u kasnijem radu programa). Do ove greške tipično dolazi ukoliko programer u jednom dijelu programa pokuša da oslobodi neki dio memorije, previdjevši da je on već ranije oslobođen u drugom dijelu programa. Razmotrimo, na primjer, sljedeći program: #include using namespace std; void f(int *niz, int br_el) { for(int i = 0; i < br_el; i++) cout << niz[i] << " "; cout << endl; delete[] niz; } int main() { int *a(new int[10]); for(int i = 0; i < 10; i++) a[i] = i * i; f(a, 10); delete[] a; return 0; }
Funkcija “f” prima pokazivač na početak nekog dinamičkog niza cijelih brojeva i broj elemenata tog niza. Ona prvo vrši ispis elemenata tog niza, a zatim oslobađa prostor koji je taj niz zauzimao. Glavni program dinamički alocira jedan niz od 10 cijelih brojeva, inicijalizira pokazivač “a” da pokazuje na početak tog niza, puni niz nekim vrijednostima i, konačno, prosljeđuje napunjeni niz funkciji “f” na obradu. Na kraju, program oslobađa niz na čiji početak pokazuje pokazivač “a”. Međutim, programer je previdio da već sama funkcija “f” oslobađa niz koji joj je povjeren na obradu, tako da u ovom primjeru dolazi do dvostrukog oslobađanja. Na većini kompajlera na kojima je autor testirao ovaj program neće doći do trenutnog kraha programa, ali se posljedice ovakve greške mogu očitovati mnogo kasnije (ukoliko se ovaj problematični isječak upotrijebi unutar nekog složenijeg programa). Ovdje razmatrani tester curenja memorije programiran je da detektira i ovakve greške. Naime, dovoljno je samo da u ovaj program na uobičajeni način uključimo tester curenja (pomoću direktive “#include "TestCurenja.h"” neposredno nakon direktive “#include ”). Ukoliko sada pokrenemo program, dobićemo ispis poput sljedećeg: 0 1 4 9 16 25 36 49 64 81 *** GRESKA: Pokusavate osloboditi vec oslobodjen prostor na adresi 003D2500!
Nažalost, tester ne može da sazna u kojoj liniji programa je došlo do dvostrukog oslobađanja (već je rečeno da je izuzetno teško saznati informaciju o liniji programa u kojoj se vrši dealokacija u vrijeme izvršavanja programa). Djelomičnu korist možemo imati ukoliko uključimo prikaz obavještenja o izvršenim alokacijama i dealokacijama. Tada ćemo dobiti prikaz poput sljedećeg:
>>> 0 1 >>> ***
U 14. liniji programa alocira se 40 bajta na adresi 003D2500 4 9 16 25 36 49 64 81 Oslobadja se 40 bajta na adresi 003D2500 GRESKA: Pokusavate osloboditi vec oslobodjen prostor na adresi 003D2500!
Na ovaj način, ako ništa drugo, barem dobijamo informaciju o tome koji se prostor u memoriji pokušava ponovo osloboditi. S obzirom da je greška dvostrukog oslobađanja fatalna, autor testera je bio u dilemi da li u slučaju njene pojave prekinuti program (nakon ispisa obavijesti o greški) ili ga nastaviti dalje. Odluka je bila da se dopusti da se program nastavi dalje, ali da pokušaj dvostrukog oslobađanja jednostavno bude ignoriran. Bitno je napomenuti da slično kao i kod detekcije curenja memorije, ovaj tester može otkriti grešku dvostrukog oslobađanja samo ukoliko se ona zaista dogodi tokom izvršavanja programa (dakle tester ne može logički otkriti da li do dvostrukog oslobađanja može doći pod izvjesnim okolnostima). Stoga je jako teško otkriti greške dvostrukog oslobađanja do kojih dolazi samo pod izvjesnim rijetkim okolnostima. Nažalost, mora se reći da postoje izvjesne situacije u kojima ovaj tester memorije ne može detektirati greške dvostrukog oslobađanja čak i ukoliko se one pojave tokom izvršavanja programa. Naime, može se desiti da pokušaj dvostrukog oslobađanja napravi dovoljnu “štetu” da izazove trenutačni krah programa prije nego što tester uspije presresti i detektirati grešku. Obično se ovo dešava kod dinamičke alokacije objekata složene strukture. Tipičan primjer je program poput sljedećeg: #include #include using namespace std; int main() { string *pok_s(new string("ABC")); delete pok_s; delete pok_s; return 0; }
Na većini kompajlera ovaj program će krahirati, sa i bez testera curenja memorije. Autoru ovog testera nije poznato može li se šta učiniti po ovom pitanju bez prepravke samog kompajlera ili standardnih biblioteka.
6. Oslobađanje zauzetog prostora na pogrešan način Još jedna klasična početnička greška je oslobađanje zauzete memorije na pogrešan način. Naime, dinamički alocirani individualni objekti oslobađaju se pomoću običnog “delete” operatora, dok se za oslobađanje dinamički alociranih nizova koristi operator “delete []”. Upotreba pogrešnog načina brisanja može također dovesti do katastrofalnih posljedica, pri čemu vjerovatnoća da će doći do posljedica raste sa porastom složenosti objekata koji se alociraju (u slučaju jednostavnih objekata poput objekata tipa “int” najvjerovatnije neće doći ni do kakvih posljedica, što svakako ne znači da takve objekte smijemo oslobađati na neispravan način). Ovaj tester pokušava (i u velikom broju slučajeva uspijeva) da detektira probleme ovog tipa (za njihovu detekciju dovoljno je uključiti tester curenja u program). Nažalost, načini kako razlikovati pokušaje brisanja na jedan i drugi način razlikuju se od kompajlera do kompajlera, pa ovaj tester pokušava raznim trikovima (zasnovanim na tipičnim načinima kako se ova razlika implementira u standardnim kompajlerima) detektirati razliku. Nažalost, nema garancije da će ti trikovi zaista raditi na svim kompajlerima (oni sigurno rade na kompajlerima iz GNU porodice kompajlera). Kao primjer, razmotrimo sljedeći trivijalan program u kojem vršimo dva brisanja na neispravan način:
#include #include "TestCurenja.h" using namespace std; int main() { int *a(new int[100]); double *b(new double(3.12)); delete a; delete[] b; return 0 }
Pokrenemo li ovaj program, dobićemo sljedeći izvještaj: *** GRESKA: Oslobadjanje na adresi 003D2500 je trebalo izvesti sa delete[]! *** GRESKA: Oslobadjanje na adresi 003D2498 nije trebalo izvesti sa delete[]!
Više informacija možemo dobiti uključimo li prikaz obavještenja o izvršenim alokacijama i dealokacijama. Tada ćemo dobiti prikaz poput sljedećeg: >>> >>> >>> *** >>> ***
U 8. liniji programa alocira se 400 bajta na adresi 003D2500 U 9. liniji programa alocira se 8 ba jta na adresi 003D2498 Oslobadja se 400 bajta na adresi 003D2500 GRESKA: Oslobadjanje na adresi 003D2500 je trebalo izvesti sa delete[]! Oslobadja se 8 bajta na adresi 003D2498 GRESKA: Oslobadjanje na adresi 003D2498 nije trebalo izvesti sa delete[]!
Slično kao pri dvostukom brisanju, tester neće prekinuti program u slučaju da se detektira brisanje na pogrešan način (nego će samo prijaviti grešku). Međutim, upitno je da li će samo brisanje biti obavljeno. U slučajevima kada se radi o jednostavnim tipovima podataka (kao u prethodnom primjeru), brisanje će ipak biti obavljeno, što se vidi iz izvještaja. Me đutim, sljedeći primjer ukazuje da to ne mora biti tako kod složenijih tipova podataka: #include #include #include "TestCurenja.h" using namespace std; int main() { UKLJUCI_OBAVJESTAVANJE; string *niz(new string[3]); delete niz; return 0; }
U ovom primjeru očigledno imamo oslobađanje dinamičkog niza na pogrešan način (trebalo je upotrijebiti “delete []”). Međutim, prikaz na ekranu će nas uvjeriti da se oslobađanje nije ni izvršilo (stoga će završni izvještaj sadržavati informaciju o curenju memorije): >>> U 9. liniji programa alocira se 16 bajta na adresi 003D2500 *** GRESKA: Oslobadjanje na adresi 003D2500 je trebalo izvesti sa delete[]!
O ovome uopće ne trebamo previše razmišljati: nama je dovoljna spoznaja da smo oslobađanje memorije pokušali izvršiti na neispravan način. Treba napomenuti da, slično kao kod detekcije dvostrukog oslobađanja, postoji mogućnost da oslobađanje zauzete memorije na pogrešan način izazove štetu koja će proizvesti krah programa prije nego što tester uspije presresti i detektirati grešku. Recimo, na većini kompajlera to će se desiti u sljedećem programu (sa i bez testera curenja):
#include #include using namespace std; int main() { string *pok_s(new string("ABC")); delete[] pok_s; return 0; }
Greška je jasna: ovdje nije trebalo upotrijebiti “delete []” već samo “delete”. Inače, mogućnost kraha je veća ukoliko se umjesto “delete” upotrijebi “delete []” nego obrnuto. Autoru ovog testera nije poznato da li se ovakva greška može nekako presresti prije nego što dođe do kraha. Srećom, u većini slučajeva tester ipak uspijeva reagirati na vrijeme.
7. Problemi sa naprednim varijantama operatora “new” Ova napomena data je više radi kompletnosti, s obzirom da izlazi izvan opsega znanja prosječnog studenta. Ipak, one koji znaju nešto više, treba znati da je radi trika koji je iskorišten sa ciljem da tester u vrijeme izvršavanja programa sazna u kojoj je liniji programa izvršena alokacija žrtvovana mogućnost upotrebe naprednijih varijanti operatora “new” kod kojih se, pored uobičajenih argumenata, dodaju i drugi argumenti specijalnog značenja. To se posebno odnosi na takozvane placement-new i nothrow-new varijante operatora “new”. Ko zna o čemu se radi, treba da zna da ovaj tester curenja onemogućava upotrebu ovih varijanti operatora “new”. Ko ne zna o čemu se radi (većina korisnika), mogu lijepo ignorirati ovo upozorenje.
8. Poznati nedostaci programa Autoru je jasno da je ovaj tester daleko od savršenog. Ovdje je rezimiran spisak nedostataka i ograničenja ovog testera koji su poznati autoru: •
•
•
•
•
•
Ovaj tester pretpostavlja da se čitav program nalazi u jednoj programskoj datoteci. Problem je lako otklonjiv, ali njegovo uklanjanje vodi ka neznatnom usložnjavanju korištenja testera (zainteresirani se mogu obratiti autoru za informacije). Tester detektuje probleme samo ako do njih dođe u toku izvršavanja programa. Probleme koji bi se eventualno mogli pojaviti pod nekim drugim okolnostima tester ne može detektirati. U općem slučaju taj problem uopće nije rješiv i ne može ga riješiti niti jedan drugi tester (mada neki složeni testeri uspijevaju logičkom analizom programa u nekim slučajevima ukazati na eventulne probleme koji bi mogli eventualno nastati). Tester onemogućava upotrebu naprednih formi operatora “new” kao što su placement-new i nothrow-new. Problem je rješiv, ali uz velike žrtve (gubitak informacija o tome u kojoj liniji programa je izvršena koja alokacija). Autoru nije poznato da li je problem rješiv bez ove žrtve ili eventualnog modificiranja samog kompajlera. Tester ne uspijeva prikazati informaciju u kojim linijama programa su izvršene pojedine dealokacije tokom rada programa. Autoru nije poznato da li je problem rješiv bez potrebe za modificiranjem samog kompajlera. Mada tester obavještava korisnika o internim alokacijama i dealokacijama, on nije u stanju da poveže koja je naredba u korisnikovom programu izazvala internu alokaciju odnosno dealokaciju. Autoru nije poznato da li je problem rješiv bez potrebe za modificiranjem samog kompajlera ili standardne biblioteke. Tester obavještava korisnika o svim internim alokacijama i dealokacijama, čak i o onim koje garantirano ne mogu napraviti nikakvu štetu, što može nervirati. Autoru nije poznato da li je na neki način moguće razlikovati “opasne” od “bezopasnih” internih alokacija odnosno dealokacija (i spriječiti ispis obavještenja o onim “bezopasnim”) bez potrebe za modificiranjem samog kompajlera ili standardne biblioteke.
•
•
•
•
Tester ne može ponuditi informaciju u kojoj liniji programa je došlo do dvostrukog oslobađanja zauzete memorije. Autoru nije poznato da li je problem rješiv bez potrebe za modificiranjem samog kompajlera. U nekim slučajevima dvostruko oslobađanje zauzete memorije može izazvati krah prije nego što tester uspije reagirati. Autoru ovog testera nije poznato da li je problem rješiv bez prepravke samog kompajlera ili standardnih biblioteka. Tester ne može uvijek detektirati oslobađanje memorije na pogrešan način (mada može u većini slučajeva). Međutim, čak i kada to uspije, tester ne može ponuditi informaciju u kojoj liniji programa je došlo do oslobađanje memorije na pogrešan način. Autoru nije poznato da li je problem rješiv bez potrebe za modificiranjem samog kompajlera. U nekim slučajevima oslobađanje memorije na pogrešan način može izazvati krah prije nego što tester uspije reagirati. Autoru ovog testera nije poznato da li je problem rješiv bez prepravke samog kompajlera ili standardnih biblioteka.
9. Historija razvoja programa Verzija 1.0, april 2010. •
Prva zvanično publikovana verzija
Verzija 1.1, maj 2010. •
Otklonjen bag koji je onemogućavao upotrebu testera ukoliko su trenutne postavke kompajlera previše striktne (tj. ukoliko se vrši temeljitija provjera poštivanja standarda nego što je to slučaj uz uobičajene postavke kompajlera). Autor se zahvaljuje Marku Laliću (u to doba studentu I godine ETF-a) na uočavanju ovog baga i sugestijama kako izvršiti njegovu korekciju.
Verzija 1.2, maj 2011. •
Otklonjen bag koji je sprečavao automatsko dealociranje memorije ukoliko pri konstrukciji dinamički alociranog objekta dođe do bacanja izuzetka iz konstruktora. Naime, mada standard jezika C++ garantira da će ukoliko pri pokušaju dinamičke alokacije nekog objekta dođe do bacanja izuzetka iz konstruktora sva memorija koja je eventualno bila zauzeta za potrebe stvaranja objekta biti automatski oslobođena (ovo se ne odnosi na dodatne alokacije memorije koje se eventualno izvrše unutar samog konstruktora), tester memorije u ovakvim slučajevima nije registrirao da je izvršena dealokacija memorije i prijavljivao je curenje memorije koje zapravo ne postoje (tehnički razlog za eksperte: placement delete operator nije bio preklopljen). Autor se zahvaljuje Adnanu Hidiću (u to doba studentu I godine ETF-a) na uočavanju ovog baga.
10. Završne napomene Ovaj tester namijenjen je da se koristi, a ne da se analizira i prepravlja. Korisnicima se ne preporučuje da pokušavaju analizirati ovaj tester, s obzirom da on predstavlja primjer “prljavog programiranja” čija analiza može samo isfrustrirati one čije znanje nije zaista veliko. Tester koristite na svoju vlastitu odgovornost. Autor ne preuzima na sebe nikakvu odgovornost koja bi mogla nastati kao posljedica rada ovog testera (u svakom slučaju, tester definitivno ne može izazvati nikakvu štetu Vašem računaru). S obzirom da se radi o radnoj verziji testera curenja, sasvim je moguće da u programu postoje izvjesne greške. Korisnici se mole da o svakoj eventualno uočenoj greški ili problemu u korištenju testera obavijeste autora na e-mail [email protected]
Sve dobronamjerne kritike i sugestije vezane za ovaj tester su dobrodošle. Autor: Doc. dr. Željko Jurić Prirodno-matematički fakultet, Sarajevo Bosna i Hercegovina
