[so] Tema1 - (Dez)alocarea memoriei

[Alex Ciminian]

Nu cred că e o problemă. Din câte am citit [1], still reachable înseamnă că
mai există un pointer activ către acea zonă de memorie; se poate să fie
false positive sau se poate să fie din cauza cachingului: "Memory for quite
a number of destructed objects is not immediately freed and given back to
the OS, but kept in the pool(s) for later re-use. The fact that the pools
are not freed at the exit() of the program cause Valgrind to report this
memory as still reachable." Am şi eu o problemă de memory leak pe care nu
ştiu cum să o rezolv. Fac nişte operaţii pe stringurile din parser, iar
rezultatul (char *) îl stochez înapoi în (word_t *)->string, care e (const
char *). Am încercat în mai multe feluri: * aici crapă pentru că nu mai
poate accesa memoria aia result = get_final_string(current); current->string
= (const char *) result; free(result); * duplicat rezultatul cu strdup şi
făcut cast result = get_final_string(current); current->string = (const char
*) strdup(result); free(result); * atribuire direct din ce returnează
funcţia current->string = get_final_string(current); În ultimele două
situaţii am leak pe malloc-ul pentru (char *)-ul returnat de funcţia
get_final_string, în prima crapă vesel. Nu îmi dau seama dacă e o problemă
de la mine sau de la free_parse_memory(), care nu mai funcţionează ca lumea
dacă se schimbă vreun pointer din structura returnată de parser. În headerul
parserului scrie clar să nu modificăm structurile de date şi să folosim aux
pentru alte date pe care vrem să le transmitem (am citit :), dar nu scria
nimic Ce aş vrea să ştiu e dacă modul meu de abordare e flawed (nu sunt
expert în C şi am încercat să îmi structurez cât mai bine programul fără să
iau în considerare "subtilităţile" astea :), dacă e o problemă în designul
parserului sau dacă ce scrie în headerul ăla ar trebui să fie completat cu
"nu modificaţi structurile şi valorile". Îmi pare rău că nu pot da exemple
de cod mai concludente sau output de valgrind, dar nu am acces acum la
maşina virtuală şi dacă las iar pe diseară nu mai trimit nimic. Mulţumesc,
Alex [1] http://valgrind.org/docs/manual/faq.html#faq.reports

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?
>
>     Multumesc!
>
> --
> Bogdan Sass
> CCAI,CCSP,JNCIA-ER,CCIE #22221 (RS)
> Information Systems Security Professional
> "Curiosity was framed - ignorance killed the cat"
>
>
> _______________________________________________
> so mailing list
> so at cursuri.cs.pub.ro
> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/so
>
>


-- 
Alex Ciminian
==========
web developer @ iLeo Bucharest
student @ 'Politehnica' University Bucharest

Phone: +40 722 252 476
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20090330/65491c4f/attachment.htm>