<span class="Apple-style-span" style="border-collapse: collapse; white-space: pre-wrap; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; ">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] <a href="http://valgrind.org/docs/manual/faq.html#faq.reports">http://valgrind.org/docs/manual/faq.html#faq.reports</a></span><br><br><div class="gmail_quote">On Mon, Mar 30, 2009 at 5:19 PM, Bogdan Sass <span dir="ltr"><<a href="mailto:bogdan.sass@catc.ro">bogdan.sass@catc.ro</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">
La rularea valgrind pe un program care foloseste parser-ul din
tema, obtin urmatorul rezultat:<br>
<br>
# valgrind ./parser/CUseParser<br>
==29053== Memcheck, a memory error detector.<br>
==29053== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et
al.<br>
==29053== Using LibVEX rev 1854, a library for dynamic binary
translation.<br>
==29053== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.<br>
==29053== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation
framework.<br>
==29053== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et
al.<br>
==29053== For more details, rerun with: -v<br>
==29053==<br>
> test<br>
Command successfully read!<br>
==29053==<br>
==29053== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from
1)<br>
==29053== malloc/free: in use at exit: 4 bytes in 1 blocks.<br>
==29053== malloc/free: 10 allocs, 9 frees, 180 bytes allocated.<br>
==29053== For counts of detected errors, rerun with: -v<br>
==29053== searching for pointers to 1 not-freed blocks.<br>
==29053== checked 96,384 bytes.<br>
==29053==<br>
==29053== LEAK SUMMARY:<br>
==29053== definitely lost: 0 bytes in 0 blocks.<br>
==29053== possibly lost: 0 bytes in 0 blocks.<br>
<b>==29053== still reachable: 4 bytes in 1 blocks.</b><br>
==29053== suppressed: 0 bytes in 0 blocks.<br>
==29053== Rerun with --leak-check=full to see details of leaked memory.<br>
<br>
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"?). <br>
<br>
Poate cineva sa imi explice ce inseamna acest "still reachable", si
daca este vorba de un memory leak sau doar de un comportament normal?<br>
<br>
Multumesc!<br><font color="#888888">
<pre cols="72">--
Bogdan Sass
CCAI,CCSP,JNCIA-ER,CCIE #22221 (RS)
Information Systems Security Professional
"Curiosity was framed - ignorance killed the cat"</pre>
</font></div>
<br>_______________________________________________<br>
so mailing list<br>
<a href="mailto:so@cursuri.cs.pub.ro">so@cursuri.cs.pub.ro</a><br>
<a href="http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/so" target="_blank">http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/so</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Alex Ciminian<br>==========<br>web developer @ iLeo Bucharest<br>student @ 'Politehnica' University Bucharest<br><br>Phone: +40 722 252 476<br><br><br><br>