Package: libstdc++5
Version: 1:3.3.2-4
Severity: minor
The memory allocated by std::map in the following sample program seems
never to be freed:
#include <map>
int main()
{
std::map<int, int> a;
}
... as the following output from valgrind suggests:
> valgrind --leak-check=yes --show-reachable=yes --num-callers=20
> --run-libc-freeres=yes ./test-map-destruction
==29180== Memcheck, a memory error detector for x86-linux.
==29180== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==29180== Using valgrind-2.1.0, a program supervision framework for x86-linux.
==29180== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==29180== Estimated CPU clock rate is 1673 MHz
==29180== For more details, rerun with: -v
==29180==
==29180==
==29180== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==29180== malloc/free: in use at exit: 960 bytes in 1 blocks.
==29180== malloc/free: 1 allocs, 0 frees, 960 bytes allocated.
==29180== For counts of detected errors, rerun with: -v
==29180== searching for pointers to 1 not-freed blocks.
==29180== checked 4529228 bytes.
==29180==
==29180== 960 bytes in 1 blocks are still reachable in loss record 1 of 1
==29180== at 0x4002CDFE: operator new(unsigned) (vg_replace_malloc.c:162)
==29180== by 0x402C8EFA: std::__default_alloc_template<true,
0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.5)
==29180== by 0x402C8E0C: std::__default_alloc_template<true,
0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.5)
==29180== by 0x402C8B07: std::__default_alloc_template<true,
0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.5)
==29180== by 0x8048E0E: std::__simple_alloc<std::_Rb_tree_node<std::pair<int
const, int> >, std::__default_alloc_template<true, 0> >::allocate(unsigned)
(stl_alloc.h:232)
==29180== by 0x8048DD1: std::_Rb_tree_alloc_base<std::pair<int const, int>,
std::allocator<std::pair<int const, int> >, true>::_M_get_node()
(stl_tree.h:564)
==29180== by 0x8048D9C: std::_Rb_tree_base<std::pair<int const, int>,
std::allocator<std::pair<int const, int> >
>::_Rb_tree_base(std::allocator<std::pair<int const, int> > const&)
(stl_tree.h:579)
==29180== by 0x8048D4D: std::_Rb_tree<int, std::pair<int const, int>,
std::_Select1st<std::pair<int const, int> >, std::less<int>,
std::allocator<std::pair<int const, int> > >::_Rb_tree(std::less<int> const&,
std::allocator<std::pair<int const, int> > const&) (stl_tree.h:730)
==29180== by 0x8048CEA: std::map<int, int, std::less<int>,
std::allocator<std::pair<int const, int> > >::map() (stl_map.h:144)
==29180== by 0x804875A: main (test-map-destruction.cc:5)
==29180==
==29180== LEAK SUMMARY:
==29180== definitely lost: 0 bytes in 0 blocks.
==29180== possibly lost: 0 bytes in 0 blocks.
==29180== still reachable: 960 bytes in 1 blocks.
==29180== suppressed: 0 bytes in 0 blocks.
I am inclined to assume that the memory is kept in some pool. If so,
having a way to make libstdc++ free it anyway would make finding real
leaks easier.
Regards,
Daniel
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux tpce14 2.4.24 #1 Mi Jan 28 09:45:36 CET 2004 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Versions of packages libstdc++5 depends on:
ii gcc-3.3-base 1:3.3.2-4 The GNU Compiler Collection (base
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an
ii libgcc1 1:3.3.2-4 GCC support library
-- no debconf information
