From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.0.6-1.2.fc4 Firefox/1.0.6 Description of problem: The memory leaks that valgrind (as shipped with FC4) knows not to report do not seem to be up to date for the version of libstdc++ shipped with FC4. There are 4 complaints on each of my programs that I've tried so far (the 4th mentions boost::regex, but the leak is deep within libstc++ so I don't think this is a boost error). No complaints with the FC3 combination. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: I'm using this commandline: valgrind -q --tool=memcheck --num-callers=7 --show-reachable=yes --leak-check=yes --logfile-fd=3 ./$1 > $2 2>&1 3>valgrind.log Actual Results: ==3711== ==3711== 40 bytes in 10 blocks are still reachable in loss record 1 of 4 ==3711== at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132) ==3711== by 0x8333D7: __gnu_cxx::__pool<true>::_M_initialize(void (*)(void*)) (in /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x834100: (within /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x833A7F: (within /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x87E38C: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x88241E: (within /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x88303B: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.5) ==3711== ==3711== ==3711== 200 bytes in 2 blocks are still reachable in loss record 2 of 4 ==3711== at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132) ==3711== by 0x833285: __gnu_cxx::__pool<true>::_M_initialize(void (*)(void*)) (in /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x834100: (within /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x833A7F: (within /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x87E38C: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x88241E: (within /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x88303B: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.5) ==3711== ==3711== ==3711== 516 bytes in 2 blocks are still reachable in loss record 3 of 4 ==3711== at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132) ==3711== by 0x833225: __gnu_cxx::__pool<true>::_M_initialize(void (*)(void*)) (in /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x834100: (within /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x833A7F: (within /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x87E38C: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x88241E: (within /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x88303B: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.5) ==3711== ==3711== ==3711== 16320 bytes in 4 blocks are still reachable in loss record 4 of 4 ==3711== at 0x1B90939A: operator new(unsigned) (vg_replace_malloc.c:132) ==3711== by 0x83302E: __gnu_cxx::__pool<true>::_M_reserve_block(unsigned, unsigned) (in /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x8339A0: (within /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x87E38C: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x88241E: (within /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x88303B: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.5) ==3711== by 0x1B940C02: boost::c_regex_traits<char>::init() (in /usr/lib/libboost_regex.so.1.32.0) Expected Results: No output. Additional info:
I don't think any library besides glibc (and other libraries included therein) include the special magic to free all used resources when asked to upon exit (by mtrace, valgrind etc.). Not freeing resources on exit is the correct thing to do, programs shouldn't bother too much with freeing resources on exit, so unless they are reported as definitely lost by valgrind, that's not a bug. But I don't want to record all exceptions for all shared libraries shipped in the distro, that really is not the way to go. So, you either should ignore those, or write exception file for yourself.
I agree with your first paragraph, but disagree with your second: I think the whole point of a distro is packages configured to work together. In addition this is a major library that all C++ programs will be using. Anyway, for anyone who googles here with the same problem, here are the exceptions I added to the bottom of /usr/lib/valgrind/default.supp. They stop the warnings for me, but no guarantee that are not stopping too much: #2005-09-27: For g++4's stdlib string memory pool "leaks" # I deleted any fun: entries after the last obj: line to hopefully make # them more general. { libstdc6 string leak 1 Memcheck:Leak fun:_Znwj fun:_ZN9__gnu_cxx6__poolILb1EE13_M_initializeEPFvPvE obj:/usr/lib/libstdc++.so.6.0.5 obj:/usr/lib/libstdc++.so.6.0.5 fun:_ZNSs4_Rep9_S_createEjjRKSaIcE obj:/usr/lib/libstdc++.so.6.0.5 } { libstdc6 string leak 2 Memcheck:Leak fun:_Znwj fun:_ZN9__gnu_cxx6__poolILb1EE13_M_initializeEPFvPvE obj:/usr/lib/libstdc++.so.6.0.5 obj:/usr/lib/libstdc++.so.6.0.5 fun:_ZNSs4_Rep9_S_createEjjRKSaIcE obj:/usr/lib/libstdc++.so.6.0.5 } { libstdc6 string leak 3 Memcheck:Leak fun:_Znwj fun:_ZN9__gnu_cxx6__poolILb1EE13_M_initializeEPFvPvE obj:/usr/lib/libstdc++.so.6.0.5 obj:/usr/lib/libstdc++.so.6.0.5 fun:_ZNSs4_Rep9_S_createEjjRKSaIcE obj:/usr/lib/libstdc++.so.6.0.5 } { libstdc6 string leak 4 Memcheck:Leak fun:_Znwj fun:_ZN9__gnu_cxx6__poolILb1EE16_M_reserve_blockEjj obj:/usr/lib/libstdc++.so.6.0.5 fun:_ZNSs4_Rep9_S_createEjjRKSaIcE obj:/usr/lib/libstdc++.so.6.0.5 }