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]
Other format: [Raw text]

Re: Libstdc++-v3 memory leakage?


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.

Best regards,

Wu Yongwei

--- 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

$ ./a
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 this issue.


Luke



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