Valgrind – ako na pamäťové úniky
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Reklama
Reklama

Valgrind – ako na pamäťové únikyValgrind – ako na pamäťové úniky

 

Valgrind – ako na pamäťové úniky

Google       Google       14. 3. 2007       11 716×

O tom, že každé alokované miesto v pamäti je treba aj uvolniť, sa píše snáď v každej publikácii o programovaní. Napriek tomu sa často stáva, že nie všetko za sebou poupratujeme. Tento problém sa týka ako začiatočníkov, tak aj skúsených programátorov, ktorí nejaký ten rôčik už programujú.

Reklama
Reklama

V prípade malých programov to nieje nič vážne. Problém nastane, ak naša aplikácia beží niekoľko dni a neustále zapĺňa pamäť. Po niekoľkých dňoch, alebo dokonca hodinách nastane pád programu. Dôvoď tohto pádu sa vola Memory Leak. Táto chyba patrí k tým zákernejším, ktoré je vo väčších projektoch neskutočne problematické nájsť. Často nám nepomôže ani klasicky debuger. Situácia sa však zlepšila príchodom C++ a možnosťou preťažiť operátory new a delete. To umožnilo jednoducho každú alokáciu zaznamenať v zozname alokácií a pri uvoľňovaní ju odtiaľ odstrániť. Na základe tohto princípu vznikli mnohé knižnice typu dmalloc. Mňa však zaujal program z názvom Valgrind (www.valgrind.org).

Výhoda valgrindu oproti ostatným je taká, že to nieje knižnica ktorú je nutne linkovať pri kompilácii, ale je to samostatný program. Valgrind nieje určený len na vyhľadávanie memory leakov, no ja osobne som si obľúbil pravé tuto jeho funkcionalitu. Poďme sa teda pozrieť, ako to funguje. Predstavme si modelovú situáciu, kedy máme program main.cpp.:


#include <iostream>
using namespace std;

int main()
{
   //alokujeme pole pre 10 int ale neuvolnime ich
   int* array = new int[10]; 
   
   cout << "Program allocate 10 ints" << endl ;
   return 0;
}

Tento program skompilujeme s debug prepínačom.


g++ -g main.cpp -o main.out

Program sa teraz normálne dá spustiť a nejaví sa, žeby obsahoval nejakú chybu. Lenže skúsme program donekonečna spúšťať v nejakom cykle. Časom dojde k vyčerpaniu pamäte a následnému pádu, pretože už nebude možné alokovať nové miesto. Pozrime sa na náš program pomocou valgrindu. Spusťme si program nasledovným postupom:

valgrind --leak-check=yes ./main.out

Myslím, že toto nepotrebuje takmer žiaden komentár a je to v celku jasná vec. Snáď poviem len to, že ak by náš program potreboval nejaké argumenty v pohode ich dopíšeme za ./main.out. Poďme sa pozrieť čo nám teda valgrind vypísal na výstup:


==5927== Memcheck, a memory error detector.
==5927== Copyright (C) 2002-2005, and GNU GPL"d, by Julian Seward et al.
==5927== Using LibVEX rev 1471, a library for dynamic binary translation.
==5927== Copyright (C) 2004-2005, and GNU GPL"d, by OpenWorks LLP.
==5927== Using valgrind-3.1.0-Debian, a dynamic binary instrumentation framework.
==5927== Copyright (C) 2000-2005, and GNU GPL"d, by Julian Seward et al.
==5927== For more details, rerun with: -v

Úplne na začiatok sa nám Valgrind iba predstavy. Číslo na začiatku riadku je ID procesu. Ďalej pokračuje výstup programu a nakoniec by nám mal Valgrind vypísať väčšie množstvo informácii, ktoré sú už pre nás podstatne zaujímavejšie. Ako prvé sa zobrazí ERROR SUMARY blok:


==5927== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==5927== malloc/free: in use at exit: 40 bytes in 1 blocks.
==5927== malloc/free: 2 allocs, 1 frees, 80 bytes allocated.
==5927== For counts of detected errors, rerun with: -v
==5927== searching for pointers to 1 not-freed blocks.
==5927== checked 129,364 bytes.

Tu hneď môžeme vidieť, že niečo nieje v poriadku. Konkrétne posledný riadok nám hovory, že 1 pamäťový blok nebol uvoľnený. Tento riadok sa tyká výhradne memory leakov. Memory leaky môžeme jednoducho vyčítať aj z 3. riadku, kde je počet alokovaných blokov a počet uvoľnených. Tento počet by mal byt rovnaký. V prípade, že free počet je menší, znamená to, že niekde sa vyskytol memory leak. Ďalej nasleduje podrobnejší zoznam memory leakov:


==5927== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==5927==    at 0x401CC6B: operator new[](unsigned) (vg_replace_malloc.c:197)
==5927==    by 0x80486B6: main (main.cpp:9)

Toto je asi najlepšia informácia, ktorú memchek poskytol. Keďže sme náš program skompilovali s debug prepínačom, Valgrind nám vypíše presne súbor a riadok na ktorom bol blok memory leaku alokovaný. V tomto prípade, je to v súbore main.cpp v riadku 9. Tam sa nachádza alokovanie nášho array poľa. Nakoniec nasleduje už len sumár memory leakov. Tu máme už len podrobnejšiu štatistiku memory leakov.


==5927== LEAK SUMMARY:
==5927==    definitely lost: 40 bytes in 1 blocks.
==5927==      possibly lost: 0 bytes in 0 blocks.
==5927==    still reachable: 0 bytes in 0 blocks.
==5927==         suppressed: 0 bytes in 0 blocks.

Poďme teda opraviť náš memory leak. Do main.cpp pridajme aj uvolnenie array. Program skompilujme a opäť spusťme cez Valgrind. Na výstupe by sme mali mať nasledujúci text:


==6073== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==6073== malloc/free: in use at exit: 0 bytes in 0 blocks.
==6073== malloc/free: 2 allocs, 2 frees, 80 bytes allocated.
==6073== For counts of detected errors, rerun with: -v
==6073== No malloc"d blocks -- no leaks are possible.

Výpis je teraz podstatne kratší, nakoľko k žiadnemu memory leaku nedošlo. Na treťom riadku vidíme, že všetko čo sme alokovali, sme aj uvolnili. Na poslednom riadku je výpis: no leaks are possible.

Valgrind je ohľadom memory leakov naozaj vďačný nastroj. Je pravda, že akonáhle program spúšťate, rýchlosť programu sa podstatne zníži, ale myslím, že výsledok stoji za to. Dúfam, že vám ušetrí množstvo času a napomôže k lepším kódom.

×Odeslání článku na tvůj Kindle

Zadej svůj Kindle e-mail a my ti pošleme článek na tvůj Kindle.
Musíš mít povolený příjem obsahu do svého Kindle z naší e-mailové adresy kindle@programujte.com.

E-mailová adresa (např. novak@kindle.com):

TIP: Pokud chceš dostávat naše články každé ráno do svého Kindle, koukni do sekce Články do Kindle.

Hlasování bylo ukončeno    
0 hlasů

Nové články

Reklama
Reklama
Obrázek ke článku Nový IT hráč na českém trhu

Nový IT hráč na českém trhu

V roce 2015 otevřela v Praze na Pankráci v budově City Tower své kanceláře společnost EPAM Systems (NYSE:EPAM), jejíž centrála se nachází v USA. Společnost byla založená v roce 1993 a od té doby prošla velkým vývojem a stále roste.

Obrázek ke článku České Radiokomunikace opět hledají nejlepší nápady pro internet věcí

České Radiokomunikace opět hledají nejlepší nápady pro internet věcí

České Radiokomunikace (CRA) pořádají druhý ročník CRA IoT Hackathonů. Zájemci z řad vývojářů a fanoušků moderních technologií mohou změřit své síly a během jediného dne sestrojit co nejzajímavější funkční prototyp zařízení, které bude komunikovat prostřednictvím sítě LoRa. CRA IoT Hackathony se letos uskuteční ve dvou fázích, na jaře a na podzim, v různých městech České republiky. Jarní běh se odstartuje 31. března v Brně a 7. dubna v Praze.

Obrázek ke článku Cloud computing je využíván stále intenzivněji

Cloud computing je využíván stále intenzivněji

Využívání cloud computingu nabývá na intenzitě. Jen v letošním roce vzroste podle analytiků trh se službami veřejného cloudu o 18 %, přičemž o téměř 37 % vzrostou služby typu IaaS. Růst o více než pětinu pak čeká služby poskytování softwaru formou služby, tedy SaaS. Aktuálním trendům v oblasti využívání cloudu se bude věnovat konference Cloud computing v praxi, která se koná 23. března. 2017 v pražském Kongresovém centru Vavruška na Karlově náměstí 5.

loadingtransparent (function() { var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true; po.src = 'https://apis.google.com/js/plusone.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s); })();
Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032017 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý