This is the mail archive of the
mailing list for the GCC project.
libstd++ Memory leak under multithreaded application ?
- To: gcc at gcc dot gnu dot org
- Subject: libstd++ Memory leak under multithreaded application ?
- From: Bjorn Wennberg <bjornw at tihlde dot org>
- Date: 17 Nov 1999 11:26:55 +0100
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
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
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.)
Bjørn Wennberg email: email@example.com
ms: +47 9599 2657