Your message dated Mon, 09 Feb 2004 17:13:22 +0100
with message-id <[EMAIL PROTECTED]>
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 +
>From [EMAIL PROTECTED] Thu Feb 05 01:25:53 2004
Return-path: <[EMAIL PROTECTED]>
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 ([EMAIL PROTECTED] [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 <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
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: <[EMAIL PROTECTED]>
Sender: "Daniel Kraft " <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
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
int main()
{
std::map 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::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.5)
==29180==by 0x402C8E0C: std::__default_alloc_template::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.5)
==29180==by 0x402C8B07: std::__default_alloc_template::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.5)
==29180==by 0x8048E0E: std::__simple_alloc >, std::__default_alloc_template >::allocate(unsigned)
(stl_alloc.h:232)
==29180==by 0x8048DD1: std::_Rb_tree_alloc_base,
std::allocator >, true>::_M_get_node()
(stl_tree.h:564)
==29180==by 0x8048D9C: std::_Rb_tree_base,
std::allocator >
>::_Rb_tree_base(std::allocator > const&)
(stl_tree.h:579)
==29180==by 0x8048D4D: std::_Rb_tree,
std::_Select1st >, std::less,
std::allocator > >::_Rb_tree(std::less const&,
std::allocator > const&) (stl_tree.h:730)
==29180==by 0x8048CEA: std::map,
std::allocator > >::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-base1:3.3.2-4Th
