libstd++ Memory leak under multithreaded application ?

[Bjorn Wennberg <bjornw at tihlde dot org>]

Hi there!

I suspect that the libstd++ library is leaking memory when running
in a multithreaded environment.

I have a multithreaded server that accepts connections. For each 
connection I spawn a thread that performs some work and exits.
For each new thread I see a memory leak of 4 bytes by using
some top-utilities. My server consumes easily 100M per day
if it is under heavy load.

The reseaon I'm suspecting libstd++ for leaking memory is this:
I explicitly went over my code and used the malloc_alloc allocater
for every stl-container such as string, list<>, map<>, set<>,
vector<> and friends. Now it does NOT leak memory.
(btw: I figured out that I could use -D__USE_MALLOC when compiling
AFTER I've done a complete rewrite of my container-declararions *sigh*)

(I have used a utility that basically uses the backtrace_symbols_fd() 
connected to libc with appropriate libc-hooks to trace who is
allocating what and who is deallocating that. However, this tool
reports that memory leeks comes from the default allocator's
chunk_alloc.)

For the record - I've experienced this under RedHat-5.0, 5.1 and 6.1
with egcs-1.1.1 and egcs-1.1.2. (I do not know the status with gcc-2.95.x)

Actually I wouldn't beleave it at first. Surely someone else must
have detected this before! I mean - stl have been out there a while.

So what am I saying? Either the memory-pool management of the default
allocated used in a MT environment is wrong OR some of the containers
do not use the allocaters correctly. E.g. I've not tried to use
default-allocator for the string-class and the malloc_alloc allocator
for the rest to find out if one container in particular is leeking.

Or I haven't understood that - HEY when you are using MT applications
and STL be sure to do this function X before the thread exists or 
something...

Please comment on this! I would rather use the default allocator than
using malloc for every bit's and piece. It's really slowing things down
at the moment :-(

(And then there were these examples proving things... well I do not
have a simple test-case but I guess I could take the time to
write one if it is desireable.)

Sincerely

bjornw>
-- 
-------------------------------------------------------
Bjørn Wennberg       email: bjornw@tihlde.org
                        ms: +47 9599 2657