|
From: tom f. <tf...@al...> - 2010-01-22 22:38:54
|
I'm seeing leaks such as [1] and [2] in an application I work on. A potential caveat is that I am compiling with _GLIBCXX_DEBUG, and thus I should be getting a debug STL -- though by the internal names I see in the symbols here, I don't appear to be getting any sort of debug bits for std::string. I'm using valgrind 3.5.0 compiled from source using gcc 4.3.2. My package manager claims I've got a matched version of libstdc++6: "4.3.2-1.1". This is on debian lenny. -tom [1] ==18113== 629 bytes in 17 blocks are possibly lost in loss record 12,309 of 12,839 ==18113== at 0x4C2196D: operator new(unsigned long) (vg_replace_malloc.c:220) ==18113== by 0x4EE16D4: __gnu_cxx::new_allocator<char>::allocate(unsigned long, void const*) (new_allocator.h:92) ==18113== by 0x4EE17D2: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (basic_string.tcc:582) ==18113== by 0x4EE1B72: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (basic_string.tcc:604) ==18113== by 0x4EFF63C: std::string::reserve(unsigned long) (basic_string.tcc:485) ==18113== by 0x4EFF710: std::string::push_back(char) (basic_string.h:874) ==18113== by 0x52246E4: std::string::operator+=(char) (basic_string.h:793) ==18113== by 0x68707FB: Connection::ReadString(std::string&) (Connection.C:390) [2] ==18113== 474 bytes in 5 blocks are possibly lost in loss record 12,208 of 12,839 ==18113== at 0x4C2196D: operator new(unsigned long) (vg_replace_malloc.c:220) ==18113== by 0x4EE16D4: __gnu_cxx::new_allocator<char>::allocate(unsigned long, void const*) (new_allocator.h:92) ==18113== by 0x4EE17D2: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (basic_string.tcc:582) ==18113== by 0x4EE1B72: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (basic_string.tcc:604) ==18113== by 0x4EFF63C: std::string::reserve(unsigned long) (basic_string.tcc:485) ==18113== by 0x4EFF7CE: std::string::append(std::string const&) (basic_string.tcc:330) ==18113== by 0x4EFF852: std::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::allocator<char> >(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (basic_string.h:2087) ==18113== by 0x521C433: PluginManager::ReadPluginInfo() (PluginManager.C:707) |
|
From: Julian S. <js...@ac...> - 2010-01-22 22:48:47
|
On Friday 22 January 2010, tom fogal wrote: > I'm seeing leaks such as [1] and [2] in an application I work on. A > potential caveat is that I am compiling with _GLIBCXX_DEBUG, and thus I > should be getting a debug STL That might be an out-of-date thing to do. See http://www.valgrind.org/docs/manual/faq.html#faq.report J |
|
From: tom f. <tf...@al...> - 2010-01-22 23:16:13
|
Julian Seward <js...@ac...> writes: > On Friday 22 January 2010, tom fogal wrote: > > I'm seeing leaks such as [1] and [2] in an application I work on. A > > potential caveat is that I am compiling with _GLIBCXX_DEBUG, and thus I > > should be getting a debug STL > > That might be an out-of-date thing to do. See > http://www.valgrind.org/docs/manual/faq.html#faq.report Argh, I've actually read that before, I was just starting valgrind manually instead of using my wrappers, which set a lot of these env vars for me. Any chance of setting this automatically when valgrind runs? Something like the attached patch? Warning: I haven't even tried compiling this, just trying to get the idea across. Seems like it would set this var even for tools like cachegrind, though. Nothing jumped out at me as a place for tool-specific initialization that would run before static initializers, though... -tom |