This is the mail archive of the
mailing list for the libstdc++ project.
Re: Libstdc++-v3 memory leakage?
- From: Wu Yongwei <adah at netstd dot com>
- To: mingw-users at lists dot sourceforge dot net, libstdc++ at gcc dot gnu dot org
- Date: Wed, 12 Mar 2003 10:14:14 +0800
- Subject: Re: Libstdc++-v3 memory leakage?
- Organization: Kingnet Security, Inc.
Thanks, Luke and Jonathan. It really works.
I strongly recommend the GLIBCPP_FORCE_NEW flag be documented in a FAQ
to ease finding memory problems.
--- Original Message from Luke Dunstan ---
I had a look at mingw/include/c++/3.2.2/bits/stl_alloc.h and I am sure
this leak is harmless because STL normally allocates memory in chunks
and keeps track of freed and allocated memory itself. The only problem
is that the underlying memory isn't freed when before the program exits
because it is in static variables. However, I also found from the source
that you can do this:
$ export GLIBCPP_FORCE_NEW=1
new: allocated 003F3CA0 (size 4, <Unknown>:0)
new: allocated 003F4CF8 (size 8, <Unknown>:0)
delete: freeing 003F3CA0 (size 4)
delete: freeing 003F4CF8 (size 8)
This environment variable causes STL to just use new & delete for all
operations which is less efficient but is useful for the type of
debugging that you are doing. Thanks for alerting other MinGW users to