Bug 169270 - valgrind complains about libstdc++
valgrind complains about libstdc++
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: valgrind (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-26 07:06 EDT by Darren Cook
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-26 12:34:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Darren Cook 2005-09-26 07:06:32 EDT
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:
Comment 1 Jakub Jelinek 2005-09-26 12:34:59 EDT
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.
Comment 2 Darren Cook 2005-09-26 21:00:14 EDT
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
}

Note You need to log in before you can comment on or make changes to this bug.