Re: STL, memory allocation, and cleanup (gcc 3.0?)

[Ulrich Eckhardt <doomster@knuut.de>]

On Monday 19 November 2001 03:27, elf@florence.buici.com wrote:
> I've written a C++ program to demonstrate behavior that I cannot
> explain.  It appears that the STL allocates memory that it never
> frees.  I'd like to believe that I'm missing something obvious, but
> then it must not be obvious enough.  Yes, I've run the debugger on it.
> It looks to be a GCC bug, but I cannot be sure since I don't have an
> explanation for the fact that a large block is allocated for the first
> Map and not for the second, *and* there are no static members in the
> Map template.
>
It is probably not a bug:
the full template for most (all?) STL-containers is 
template<class Element, class Allocator=std::allocator<Element> >

This allocator is a wrapper around the memory-management. I think there is a 
simple example for this in Stroustrup's Bible, as far as I remember, it went 
like this:
- the allocator has only static functions
- the allocator is asked for a pointer to n contiguous elements. If it has 
some memory of proper size in its internal cache, it hands these to the 
container, else it calls eg malloc to get more.
- when it is not needed anymore, the memory is given back to the allocator 
which adds the mem to its internal queue
- when an operator new fails, the new_handler-function is called, first 
requesting the allocators to free their surplus memory, if that is not 
enough, the finalizing bad_allow is thrown.

I also remember seeing an alternate implementation on www.codeguru.com, if 
you're interested.


> The program hooks new/delete and malloc/free, printing messages when
> one is called.  This all arose because I am using nearly identical
> code in another application to prove that it is memory conservative.
With your hooks, you're entering shallow waters here: there is no guarantee 
that all code is templatized, there can well be some part in a shared lib 
that then uses malloc without you seeing it.

[snipped code]
after adding a std:: here and there, this is the result with g++-3.0:
uli@doommachine:uli$ ./a.out 
map_p
malloc 12 -> 0x804c530
free 0x804c530
map_p
malloc 12 -> 0x804c530
free 0x804c530
uli@doommachine:uli$