[so] Tema1 - (Dez)alocarea memoriei

Cosmin Ratiu cosminratiu at gmail.com
Mon Mar 30 17:33:17 EEST 2009


On Mon, Mar 30, 2009 at 5:19 PM, Bogdan Sass <bogdan.sass at catc.ro> wrote:

>      La rularea valgrind pe un program care foloseste parser-ul din tema,
> obtin urmatorul rezultat:
>
> # valgrind ./parser/CUseParser
> ==29053== Memcheck, a memory error detector.
> ==29053== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==29053== Using LibVEX rev 1854, a library for dynamic binary translation.
> ==29053== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==29053== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation
> framework.
> ==29053== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==29053== For more details, rerun with: -v
> ==29053==
> > test
> Command successfully read!
> ==29053==
> ==29053== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
> ==29053== malloc/free: in use at exit: 4 bytes in 1 blocks.
> ==29053== malloc/free: 10 allocs, 9 frees, 180 bytes allocated.
> ==29053== For counts of detected errors, rerun with: -v
> ==29053== searching for pointers to 1 not-freed blocks.
> ==29053== checked 96,384 bytes.
> ==29053==
> ==29053== LEAK SUMMARY:
> ==29053==    definitely lost: 0 bytes in 0 blocks.
> ==29053==      possibly lost: 0 bytes in 0 blocks.
> *==29053==    still reachable: 4 bytes in 1 blocks.*
> ==29053==         suppressed: 0 bytes in 0 blocks.
> ==29053== Rerun with --leak-check=full to see details of leaked memory.
>
>     Din cate am reusit sa imi dau seama, este vorba de niste structuri
> yylex care raman alocate la terminare. Ce nu imi dau seama din ce citesc
> este daca acest lucru reprezinta sau nu o problema ("lost" inteleg ce
> inseamna, dar "still reachable"?).
>
>     Poate cineva sa imi explice ce inseamna acest "still reachable", si
> daca este vorba de un memory leak sau doar de un comportament normal?
>
>
Din cate pot specula pe baza a ceea ce scrie in 'man valgrind', s-ar putea
sa fie blocuri la care sa fi gasit pointeri care pointeaza spre *interiorul*
blocului de memorie, nu la inceput. S-ar putea de asemenea sa fie alarma
falsa. "--leak-check=full" zice ceva in plus?

Cosmin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20090330/4fa00058/attachment.htm>


More information about the so mailing list