Re: [Plib-devel] Memory leaks, was: GL_COLOR_MATERIAL pitfall

[Eero P. <epa...@ko...>]

Wolfram Kuss wrote:
> 
> Eero,
> 
> I dont quite understand you.
> I know there are Purify and Boundschecker
> and a few other commercial toolkits.
> AFAIK Boehm is the name of a GC
> ALGORITHM.
>

See for example:

http://reality.sgi.com/boehm/gc.html

> If the toolkit you speek about is free, where can one get it?
> 
> >It is usefull
> >because it only complains from leaked memory areas.
> >It doesn't complain just because you don't free
> >those areas which you allocate in the begining, and use to
> >the end of program run.
> 
> Interesting! How does it differentiate between
> "real leaks" and memory that is used up to the end?
> 


A memory block is live, if there is a valid pointer
pointing to it. A pointer is valid if it
is a local or global variable or if it is in a valid block.
So a whole tree becomes leaked, if you lose its
root pointer.

The gc library goes through all the variable data areas
(+ registers) to find the first level pointers, and then
follows the pointers from the memory blocks.

Now it is possible that for example an integer
or a floating point value looks like a pointer,
this causes some leaks to be undetected, but 
in practise the effect is not too bad.
(I think the library tries to avoid allocating
blocks with "trivial" bit pattern adresses)

I suspect that using custom allocators
(STL??) propably decreases the efficiency
of the GC/leak detection, but at least STLport
can be forced to use malloc.



		Eero