|
From: Christian P. <tr...@ge...> - 2005-09-12 12:56:44
|
Hi, I guess it's time to ask what the difference between those leaks is. definitely lost, I guess, means that my own app mmap()d them, indirectly lost, I guess, is memory that's lost because something else has = not=20 been freed (however vg detects this). and still reachable? all lost bytes shall be reachable somehow. so, what's meant with this then? Thanks in advance, Christian Parpart. |
|
From: Tom H. <to...@co...> - 2005-09-12 13:08:56
|
In message <200...@ge...>
Christian Parpart <tr...@ge...> wrote:
> I guess it's time to ask what the difference between those leaks is.
> definitely lost, I guess, means that my own app mmap()d them,
> indirectly lost, I guess, is memory that's lost because something else has not
> been freed (however vg detects this).
> and still reachable? all lost bytes shall be reachable somehow.
It's quite simple:
- Definitely lost means that a block of memory has not been freed
and valgrind cannot find any pointers to it
- Possibly lost eans that a block of memory has not been freed
and valgrind cannot find any pointers to the start of it but
can find at least one pointer into the middle of it
- Indirectly lost means that a block of memory has not been freed
and all the pointers to it that valgrind can find are in other
blocks marked as lost
- Still reachable means that a block of memory has not been freed
but there are still valid pointers to the start of that block in
registers or memory that has not been freed
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christian P. <tr...@ge...> - 2005-09-13 00:06:17
|
On Monday 12 September 2005 15:08, Tom Hughes wrote: > In message <200...@ge...> > > Christian Parpart <tr...@ge...> wrote: > > I guess it's time to ask what the difference between those leaks is. > > definitely lost, I guess, means that my own app mmap()d them, > > indirectly lost, I guess, is memory that's lost because something else > > has not been freed (however vg detects this). > > and still reachable? all lost bytes shall be reachable somehow. many thanks for the rather detailed description - I seem to understand them= =20 all except the last one (regarding my problem :) [...] > - Still reachable means that a block of memory has not been freed > but there are still valid pointers to the start of that block in > registers or memory that has not been freed you meen "has not been freed AND there are still valid pointers to this are= a"? I guess I need to examine where these pointers are coming from to see who=20 holds a pointer to this piece of memory - but as I've only these "still=20 reachables" who could point onto them otherwise? static vars / or some=20 unfreed stuff because a ~destructor hasn't been invoked by glibc for some=20 global static variable (C++). Thanks, Christian Parpart. |
|
From: Tom H. <to...@co...> - 2005-09-13 06:16:31
|
In message <200...@ge...>
Christian Parpart <tr...@ge...> wrote:
> On Monday 12 September 2005 15:08, Tom Hughes wrote:
>
> [...]
> > - Still reachable means that a block of memory has not been freed
> > but there are still valid pointers to the start of that block in
> > registers or memory that has not been freed
>
> you meen "has not been freed AND there are still valid pointers to this area"?
That's it, yes.
> I guess I need to examine where these pointers are coming from to see who
> holds a pointer to this piece of memory - but as I've only these "still
> reachables" who could point onto them otherwise? static vars / or some
> unfreed stuff because a ~destructor hasn't been invoked by glibc for some
> global static variable (C++).
At program end it would typically be a static variable which holds
a pointer to memory that has not been freed - still reachable memory
doesn't normally represent a problem at all as there is no need to
free everything before exiting on Unix systems.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|