"memory leaks" in std::vector container?

[Mike Krasnik]

Hello all,

I've been messing with checking memory leaks last time, and it looks
like some of the memory was not freed due to the fact
"library's default allocators keep free memory in a pool for later reuse,
rather than returning it to the OS."

In C it can be easily avoided using function
extern "C" void __libc_freeres(void);

It would be nice if something like that existed
in libstdc++. So we can get rid of these nasty
"memory leaks" while using memory debugger.

Anyone has a clue?

Thnx, Miha

 

[Gianni Mariani]

Hello all,

I've been messing with checking memory leaks last time, and it looks
like some of the memory was not freed due to the fact
"library's default allocators keep free memory in a pool for later reuse,
rather than returning it to the OS."

In C it can be easily avoided using function
extern "C" void __libc_freeres(void);

It would be nice if something like that existed
in libstdc++. So we can get rid of these nasty
"memory leaks" while using memory debugger.

Anyone has a clue?

If you're using GCC 3.2+ then there is an environment variable you can
set to call malloc/free for each allocation. Pre GCC 3.2 you had to
build a separate libstdc++.

I think the environment variable is GLIBCPP_FORCE_NEW, I'm not sure.
You'll find it in google.

As for VC++ or others, I don't know.

G

 

[Mike Krasnik]

If you're using 3.2+ then there is an environment variable you can
set to call malloc/free for each allocation. Pre GCC 3.2 you had to
build a separate libstdc++.

I think the environment variable is GLIBCPP_FORCE_NEW, I'm not sure.
You'll find it in google.

I have tried to use Valgrind and found in mini-FAQ for valgrind solution
"- With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using the
STL with -D__USE_MALLOC. Beware! This is removed from gcc
starting with version 3.3.
- With 3.2.2 and later, you should export the environment
variable GLIBCPP_FORCE_NEW before running your program."

Miha