This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: libstdc++/4164: 33 Memory Leak when using iostream


In article <20010829084914.11920.qmail@sourceware.cygnus.com> you write:

> I wrote a Memmory Leak tracker on Linux. When
> I do a simple code as:
> #include<iostream>
> int main(void){return0}
>
> I got 33 various memory leak from libstdc++.
> Note that there is no such memory leak with g++-2.95.
> here is there backtrace:

> 4112 bytes allocated during the execution
> 4020 bytes are in 33 memory leak
> 0 call to free with a invalid pointer
> 0 altered bytes

I don't have a memory leak tracker handy, but I do have a leak
detector on FreeBSD.  I see 16 "leaks" with your program (however this
can vary between port configurations) and a mainline g++ built 8/21.
However, unless things have changed recently, the number of leaks does
not accumulate as the size of the program increases.  I.e. I can use
library features from that header without additional "leaking".

If that is a memory leak (and I will not debate it since I'm sure it
has been debated on the libstdc++ mailing list), then some people
would consider it harmless unless a systematic leak developed during
run-time.  I.e. it is generally considered OK for a library to
allocate a bounded amount of memory for operations.  I.e. you would
need to run a series of programs that each created additional objects
related to that header.  If the "leaked" memory was bounded, then I am
not sure it should be considered a bug or even a "QoI" bug.

BTW, there is a practical reason why this memory is being "leaked" in
your example.  Consider that memory for a global object is being
allocated through std::__default_alloc_template<true, 0>::_S_chunk_alloc()
[This is the caching memory allocator, see stl_alloc.h.]

Consider the lifetimes of global objects under C++ (in particular,
guarantees related to the order that they are destroyed).  Now you
should see why memory obtained from operator new/malloc which is
subdivided by the caching allocator (itself a global object) might not
be returned to the system when the other global objects of a library
are deleted by the run-time.  In any event, the straightforward
implementation of the caching memory allocator for STL will never
return memory to the system for this very reason and other
performance-related reasons.

If you do not like this behavior, you can force allocators to map
directly to new/delete with no caching effect.  How to do that is
beyond the scope of this reply to your bug report.  Please see the
documents distributed with the libstdc++-v3 code.

Why didn't you see this "leak" with 2.95?  It is possible that that
implementation of the library that came with that version only used
global variable which did not themselves allocate any memory using the
default STL memory allocators.  However, this is sheer speculation
on my part.

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]