Re: Memory Leak using STL - gcc-3.2 and gcc-2.95.3

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

>	After checking for leaks in C++ programs compiled with gcc I found the
> following, both in 3.2and 2.95.3


> #include <list>
> #include <mcheck.h>
> using namespace std;
> void boo() {
>   list<int> l;
> }
> int main()
> {
>   mtrace();
>   boo();
>   return 0;
> }

Your findings are correct but they are not considered a bug.  The
memory for l goes back into a cache held within the C++ library; it is
not systemically leaked.  Compare this program:

#include <list>
#include <mcheck.h>
using namespace std;
void boo() {
  list<int> l;
}
int main()
{
  mtrace();
  for (int i = 0; i < 10000000; i++)
    boo();
  return 0;
}

A systemic leak would "leak" 10,000,000 as much memory as your posted
example.  Since the "leak" is identical for both programs, it is not
systemic and thus not a leak by reasonable definitions.  BTW, if you
were to use tools to look for "leaks" which study when no more
pointers point to memory allocated by the "program (and all used
libraries)" from the "OS (and wrappers in libc)", it will not consider
the case you found to be a leak.

BTW, as a C++ library maintainer, I'd be happy to change the default
behavior of this cache (i.e. turn it off).  However, it would impact
performance, in a major way, on the very platform for which we receive
the most complaints about this being a memory leak.

There is an outstanding request to improve the ability of users to
tune this situation without recompiling their application but (a) it
will be an ABI change AFAICS (since we exposed way too much detail in
our installed headers); and (b) no patch has been presented.

Regards,
Loren
-- 
Loren J. Rittle, Principal Staff Engineer, Motorola Labs (IL02/2240)
rittle@labs.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672