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

Loren James Rittle rittle@latour.rsch.comm.mot.com
Fri Oct 4 15:39:00 GMT 2002


>	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



More information about the Libstdc++ mailing list