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

Bug#231233: marked as done (libstdc++5: std::map memory is not freed)



Your message dated Mon, 09 Feb 2004 17:13:22 +0100
with message-id <E1AqE2E-0000qM-00@tpce14.tm.uka.de>
and subject line Bug#231233: libstdc++5: std::map memory is not freed
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--------------------------------------
Received: (at submit) by bugs.debian.org; 5 Feb 2004 09:25:53 +0000
>From postmaster@tpce14.tm.uka.de Thu Feb 05 01:25:53 2004
Return-path: <postmaster@tpce14.tm.uka.de>
Received: from mailgate.rz.uni-karlsruhe.de [129.13.64.97] (exim)
	by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
	id 1Aoflg-0007ky-00; Thu, 05 Feb 2004 01:25:53 -0800
Received: from tpce14.tm.uka.de (mail@i70pc09.tm.uni-karlsruhe.de [141.3.66.83])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.36 #1)
	id 1Aofle-0005rg-00; Thu, 05 Feb 2004 10:25:50 +0100
Received: from kraft by tpce14.tm.uka.de with local (Exim 3.36 #1 (Debian))
	id 1Aofld-0007co-00; Thu, 05 Feb 2004 10:25:50 +0100
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Daniel Kraft <da_kraft@web.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libstdc++5: std::map memory is not freed
X-Mailer: reportbug 2.39
Date: Thu, 05 Feb 2004 10:25:49 +0100
Message-Id: <[🔎] E1Aofld-0007co-00@tpce14.tm.uka.de>
Sender: "Daniel Kraft <daniel.kraft>" <daniel.kraft@tm.uka.de>
Delivered-To: submit@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_02_01 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-3.0 required=4.0 tests=HAS_PACKAGE,HTML_10_20 
	autolearn=no version=2.60-bugs.debian.org_2004_02_01
X-Spam-Level: 

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


---------------------------------------
Received: (at 231233-done) by bugs.debian.org; 9 Feb 2004 16:13:26 +0000
>From postmaster@tpce14.tm.uka.de Mon Feb 09 08:13:26 2004
Return-path: <postmaster@tpce14.tm.uka.de>
Received: from mailgate.rz.uni-karlsruhe.de [129.13.64.97] (exim)
	by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
	id 1AqE2I-0008HW-00; Mon, 09 Feb 2004 08:13:26 -0800
Received: from tpce14.tm.uka.de (mail@i70pc09.tm.uni-karlsruhe.de [141.3.66.83])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.36 #1)
	id 1AqE2E-0000SH-00; Mon, 09 Feb 2004 17:13:22 +0100
Received: from localhost
	([127.0.0.1] helo=tm.uka.de ident=kraft)
	by tpce14.tm.uka.de with esmtp (Exim 3.36 #1 (Debian))
	id 1AqE2E-0000qM-00
	for <231233-done@bugs.debian.org>; Mon, 09 Feb 2004 17:13:22 +0100
X-Mailer: exmh version 2.5 07/13/2001 (debian 2.5-1) with nmh-1.1-RC1
From: "Daniel Kraft" <daniel.kraft@tm.uka.de>
To: 231233-done@bugs.debian.org
Subject: Re: Bug#231233: libstdc++5: std::map memory is not freed
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 09 Feb 2004 17:13:22 +0100
Message-Id: <E1AqE2E-0000qM-00@tpce14.tm.uka.de>
Delivered-To: 231233-done@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_02_01 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=no 
	version=2.60-bugs.debian.org_2004_02_01
X-Spam-Level: 

That works, of course.

Sorry for asking a FAQ ... I had somehow mixed this up with
__libc_freeres() in my remembrance, which of course didn't help.

Thanks,
Daniel



Reply to: