C++'s std::string pools, debug builds? std::string and valgrind problems

Question

I have a problem with many valgrind warnings about possible memory leaks in std::string, like this one:

120 bytes in 4 blocks are possibly lost in loss record 4,192 of 4,687
    at 0x4A06819: operator new(unsigned long) (vg_replace_malloc.c:230)
    by 0x383B89B8B0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.8)
    by 0x383B89C3B4: (within /usr/lib64/libstdc++.so.6.0.8)
    by 0x383B89C4A9: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.8)

I'm wondering:

• does std::string (GCC 4.1.2) use any memory pools?
• if so, is there any way to disable the pools (in form of a debug build etc.)?

Answer 1

Check the FAQ. There is a section about “Memory leaks” in containers. You should

• check your version of Valgrind
• use a debug build of your program (and un-optimized)
• and define GLIBCXX_FORCE_NEW if necessary. (This is an environment variable that affects your program's runtime behavior, not a compile-time #define as you might expect.)

Answer 2

This seems like a false positive. This can be suppressed as described in the manual

Answer 3

If I remember correctly, many STL allocators implement some kind of retention of memory. IE they do not release the memory allocated right away, but keep it around and reuse it. I certainly had many false positives in valgrind coming from memory allocated by my STL implementation.

The best way I have found to deal with the problem is (simply) to use the suppression file.

Answer 4

120 bytes are not enough for the pool. Do you exit() from your program?