[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#231233: libstdc++5: std::map memory is not freed



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: LANG=de_DE@euro, LC_CTYPE=de_DE@euro

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




Reply to: