Valgrind在包含＜iostream＞的程序中检测出现的异常情况

test.cpp

#include <iostream>
int main() {
  return 0;
}

g++ test.cpp -o test

valgrind --tool=memcheck --leak-check=full ./test

==15749== Memcheck, a memory error detector
==15749== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==15749== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==15749== Command: ./test
==15749==
==15749==
==15749== HEAP SUMMARY:
==15749==     in use at exit: 72,704 bytes in 1 blocks
==15749==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==15749==
==15749== LEAK SUMMARY:
==15749==    definitely lost: 0 bytes in 0 blocks
==15749==    indirectly lost: 0 bytes in 0 blocks
==15749==      possibly lost: 0 bytes in 0 blocks
==15749==    still reachable: 72,704 bytes in 1 blocks
==15749==         suppressed: 0 bytes in 0 blocks
==15749== Reachable blocks (those to which a pointer was found) are not shown.
==15749== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==15749==
==15749== For counts of detected and suppressed errors, rerun with: -v
==15749== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

================================================================

出现上面的情况不必担心，这是valgrind 的bug， 大概意思是valgrind 没法及时检测到线程池的释放！

First of all: relax, it's probably not a bug, but a feature. Many implementations of the C++ standard libraries use their own memory pool allocators. Memory for quite a number of destructed objects is not immediately freed and given back to the OS, but kept in the pool(s) for later re-use. The fact that the pools are not freed at the exit of the program cause Valgrind to report this memory as still reachable. The behaviour not to free pools at the exit could be called a bug of the library though.

Using GCC, you can force the STL to use malloc and to free memory as soon as possible by globally disabling memory caching. Beware! Doing so will probably slow down your program, sometimes drastically.

With GCC 2.91, 2.95, 3.0 and 3.1, compile all source using the STL with -D__USE_MALLOC. Beware! This was removed from GCC starting with version 3.3.

With GCC 3.2.2 and later, you should export the environment variable GLIBCPP_FORCE_NEW before running your program.

With GCC 3.4 and later, that variable has changed name to GLIBCXX_FORCE_NEW.

Valgrind

c++ - Valgrind: Memory still reachable with trivial program using <iostream> - Stack Overflowhttps://stackoverflow.com/questions/30376601/valgrind-memory-still-reachable-with-trivial-program-using-iostream