[so] Tema1 - (Dez)alocarea memoriei

andrei dragus andreidragus at yahoo.com
Mon Mar 30 17:55:02 EEST 2009





--- On Mon, 3/30/09, Cosmin Ratiu <cosminratiu at gmail.com> wrote:

> From: Cosmin Ratiu <cosminratiu at gmail.com>
> Subject: Re: [so] Tema1 - (Dez)alocarea memoriei
> To: "Sisteme de Operare" <so at cursuri.cs.pub.ro>
> Date: Monday, March 30, 2009, 10:33 AM
> 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.
> _______________________________________________
> so mailing list
> so at cursuri.cs.pub.ro
> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/so

E ceva de genu:

still reachable = exista variabile globale care pointeaza la inceputul zonei de memorie (nu e neaparat leak, poate ai nevoie de structura respectiva pana in ultimul moment)

possibly lost = exista variabile globale care pointeaza spre zona de memorie (nu neaparat la inceput)





Exemplu:

#include <string.h>
#include<malloc.h>
char * p1;

char * p3;
char * nimic2()
{
	char * p2 = (char*) malloc(20);
	return p2;
}

int main()
{
	p1 = (char *) malloc(10);
	char * p2= nimic2();
	char * p4 = malloc(30);
	p3 = p4+1;
	return 0;
}

Output:

==2336== 
==2336== LEAK SUMMARY:
==2336==    definitely lost: 20 bytes in 1 blocks.
==2336==      possibly lost: 30 bytes in 1 blocks.
==2336==    still reachable: 10 bytes in 1 blocks.
==2336==         suppressed: 0 bytes in 0 blocks.
==2336== Rerun with --leak-check=full to see details of leaked memory.




      


More information about the so mailing list