Bug#275023: marked as done (g++-3.4: valgrind reports vectors don't free their memory)
Your message dated Thu, 18 Aug 2005 11:06:13 +0200
with message-id <17156.20357.670612.740584@gargle.gargle.HOWL>
and subject line Bug#275023: g++-3.4: valgrind reports vectors don't free their memory
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 Oct 2004 14:50:48 +0000
>From moritz@bunkus.org Tue Oct 05 07:50:47 2004
Return-path: <moritz@bunkus.org>
Received: from bunkus.org (p15097576.pureserver.info) [217.160.128.146]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1CEqeN-0007On-00; Tue, 05 Oct 2004 07:50:47 -0700
Received: from localhost (localhost.localdomain [127.0.0.1])
by p15097576.pureserver.info (Postfix) with ESMTP id 0E8BB440074;
Tue, 5 Oct 2004 16:50:46 +0200 (CEST)
Received: from p15097576.pureserver.info ([127.0.0.1])
by localhost (p15097576 [127.0.0.1]) (amavisd-new, port 10024) with SMTP
id 31071-05; Tue, 5 Oct 2004 16:50:45 +0200 (CEST)
Received: from jaina.no-ip.com (port-212-202-180-232.dynamic.qsc.de [212.202.180.232])
by p15097576.pureserver.info (Postfix) with ESMTP id 8924044006B;
Tue, 5 Oct 2004 16:50:44 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
by jaina.no-ip.com (Postfix) with ESMTP id 95A6D5499191;
Tue, 5 Oct 2004 16:50:43 +0200 (CEST)
Received: from jaina.no-ip.com ([127.0.0.1])
by localhost (jaina [127.0.0.1]) (amavisd-new, port 10024) with SMTP
id 02638-03; Tue, 5 Oct 2004 16:50:42 +0200 (CEST)
Received: by jaina.no-ip.com (Postfix, from userid 500)
id 599705499187; Tue, 5 Oct 2004 16:50:42 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Moritz Bunkus <moritz@bunkus.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: g++-3.4: valgrind reports vectors don't free their memory
X-Mailer: reportbug 2.62
Date: Tue, 05 Oct 2004 16:50:41 +0200
Message-Id: <20041005145042.599705499187@jaina.no-ip.com>
X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at bunkus.org
X-Virus-Scanned: by amavisd-new at bunkus.org
Delivered-To: submit@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
Package: g++-3.4
Version: 3.4.2-2
Severity: normal
Maybe this is not a bug in g++ but in valgrind, or maybe it isn't a
bug at all, so my apologies if this is wrong here. Anyway.
A program using std::vector compiled with g++-3.4 spits out a lot of
warnings when it is run under valgrind with leak checking enabled. The
same source code compiled with g++-3.3 produces only one of those
entries with valgrind.
This short (and very useless) program demonstrates it:
---------------------------
#include <vector>
using namespace std;
typedef struct {
int i;
char c;
} some_struct_t;
void some_func() {
vector<some_struct_t> v;
some_struct_t s;
s.i = 42;
s.c = 'd';
v.push_back(s);
s.i = 54;
s.c = 'a';
v.push_back(s);
}
int main() {
some_func();
return 0;
}
----------------------------
Compilation: g++-3.4 -o testme-3.4 testme.cpp
valgrind 2.2.0-2 (Debian package), command line:
valgrind --leak-check=yes --show-reachable=yes ./testme-3.4
Output:
-----------------------------
==16676== Memcheck, a memory error detector for x86-linux.
==16676== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==16676== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==16676== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==16676== For more details, rerun with: -v
==16676==
==16676==
==16676== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==16676== malloc/free: in use at exit: 8518 bytes in 9 blocks.
==16676== malloc/free: 10 allocs, 1 frees, 8530 bytes allocated.
==16676== For counts of detected errors, rerun with: -v
==16676== searching for pointers to 9 not-freed blocks.
==16676== checked 2446368 bytes.
==16676==
==16676== 20 bytes in 5 blocks are still reachable in loss record 1 of 4
==16676== at 0x1B90506F: operator new(unsigned) (vg_replace_malloc.c:133)
==16676== by 0x8049C03: __gnu_cxx::__mt_alloc<some_struct_t>::_S_initialize() (in /home/mosu/tmp/testme-3.4)
==16676== by 0x80493AC: __gnu_cxx::__mt_alloc<some_struct_t>::allocate(unsigned, void const*) (in /home/mosu/tmp/testme-3.4)
==16676== by 0x8048FB5: std::_Vector_base<some_struct_t, std::allocator<some_struct_t> >::_M_allocate(unsigned) (in /home/mosu/tmp/testme-3.4)
==16676==
==16676==
==16676== 80 bytes in 1 blocks are still reachable in loss record 2 of 4
==16676== at 0x1B90506F: operator new(unsigned) (vg_replace_malloc.c:133)
==16676== by 0x80499C9: __gnu_cxx::__mt_alloc<some_struct_t>::_S_initialize() (in /home/mosu/tmp/testme-3.4)
==16676== by 0x80493AC: __gnu_cxx::__mt_alloc<some_struct_t>::allocate(unsigned, void const*) (in /home/mosu/tmp/testme-3.4)
==16676== by 0x8048FB5: std::_Vector_base<some_struct_t, std::allocator<some_struct_t> >::_M_allocate(unsigned) (in /home/mosu/tmp/testme-3.4)
==16676==
==16676==
==16676== 258 bytes in 1 blocks are still reachable in loss record 3 of 4
==16676== at 0x1B90506F: operator new(unsigned) (vg_replace_malloc.c:133)
==16676== by 0x8049953: __gnu_cxx::__mt_alloc<some_struct_t>::_S_initialize() (in /home/mosu/tmp/testme-3.4)
==16676== by 0x80493AC: __gnu_cxx::__mt_alloc<some_struct_t>::allocate(unsigned, void const*) (in /home/mosu/tmp/testme-3.4)
==16676== by 0x8048FB5: std::_Vector_base<some_struct_t, std::allocator<some_struct_t> >::_M_allocate(unsigned) (in /home/mosu/tmp/testme-3.4)
==16676==
==16676==
==16676== 8160 bytes in 2 blocks are still reachable in loss record 4 of 4
==16676== at 0x1B90506F: operator new(unsigned) (vg_replace_malloc.c:133)
==16676== by 0x804960B: __gnu_cxx::__mt_alloc<some_struct_t>::allocate(unsigned, void const*) (in /home/mosu/tmp/testme-3.4)
==16676== by 0x8048FB5: std::_Vector_base<some_struct_t, std::allocator<some_struct_t> >::_M_allocate(unsigned) (in /home/mosu/tmp/testme-3.4)
==16676== by 0x8048C9B: std::vector<some_struct_t, std::allocator<some_struct_t> >::_M_insert_aux(__gnu_cxx::__normal_iterator<some_struct_t*, std::vector<some_struct_t, std::allocator<some_struct_t> > >, some_struct_t const&) (in /home/mosu/tmp/testme-3.4)
==16676==
==16676== LEAK SUMMARY:
==16676== definitely lost: 0 bytes in 0 blocks.
==16676== possibly lost: 0 bytes in 0 blocks.
==16676== still reachable: 8518 bytes in 9 blocks.
==16676== suppressed: 0 bytes in 0 blocks.
-----------------------------
With a "proper" program its output becomes even more verbose and makes
finding real issues in the program very hard.
g++-3.3 -o testme-3.3 testme.cpp
valgrind --leak-check=yes --show-reachable=yes ./testme-3.3
Output:
-----------------------------
==17180== Memcheck, a memory error detector for x86-linux.
==17180== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==17180== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==17180== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==17180== For more details, rerun with: -v
==17180==
==17180==
==17180== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==17180== malloc/free: in use at exit: 320 bytes in 1 blocks.
==17180== malloc/free: 1 allocs, 0 frees, 320 bytes allocated.
==17180== For counts of detected errors, rerun with: -v
==17180== searching for pointers to 1 not-freed blocks.
==17180== checked 2343248 bytes.
==17180==
==17180== 320 bytes in 1 blocks are still reachable in loss record 1 of 1
==17180== at 0x1B90506F: operator new(unsigned) (vg_replace_malloc.c:133)
==17180== by 0x1B999BFA: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.6)
==17180== by 0x1B999B0C: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.6)
==17180== by 0x1B999807: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.6)
==17180==
==17180== LEAK SUMMARY:
==17180== definitely lost: 0 bytes in 0 blocks.
==17180== possibly lost: 0 bytes in 0 blocks.
==17180== still reachable: 320 bytes in 1 blocks.
==17180== suppressed: 0 bytes in 0 blocks.
-----------------------------
Thanks, Mosu
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.4.26
Locale: LANG=en_US, LC_CTYPE=en_US
Versions of packages g++-3.4 depends on:
ii gcc-3.4 3.4.2-2 The GNU C compiler
ii gcc-3.4-base 3.4.2-2 The GNU Compiler Collection (base
ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries an
ii libstdc++6-dev 3.4.2-2 The GNU Standard C++ Library v3 (d
-- no debconf information
---------------------------------------
Received: (at 275023-done) by bugs.debian.org; 18 Aug 2005 09:06:18 +0000
>From doko@cs.tu-berlin.de Thu Aug 18 02:06:18 2005
Return-path: <doko@cs.tu-berlin.de>
Received: from mail.cs.tu-berlin.de [130.149.17.13] (root)
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1E5gLq-0006Pq-00; Thu, 18 Aug 2005 02:06:18 -0700
Received: from mailhost.cs.tu-berlin.de (postfix@mail.cs.tu-berlin.de [130.149.17.13])
by mail.cs.tu-berlin.de (8.9.3p2/8.9.3) with ESMTP id LAA21934;
Thu, 18 Aug 2005 11:06:15 +0200 (MEST)
Received: from localhost (localhost [127.0.0.1])
by mailhost.cs.tu-berlin.de (Postfix) with ESMTP id 50DA2FD4F;
Thu, 18 Aug 2005 11:06:15 +0200 (MEST)
Received: from mailhost.cs.tu-berlin.de ([127.0.0.1])
by localhost (bueno [127.0.0.1]) (amavisd-new, port 10224) with ESMTP
id 29605-20; Thu, 18 Aug 2005 11:06:14 +0200 (MEST) 11332
Received: from bolero.cs.tu-berlin.de (bolero.cs.tu-berlin.de [130.149.19.1])
by mailhost.cs.tu-berlin.de (Postfix) with ESMTP;
Thu, 18 Aug 2005 11:06:13 +0200 (MEST)
Received: (from doko@localhost)
by bolero.cs.tu-berlin.de (8.12.10+Sun/8.12.8/Submit) id j7I96DG8013012;
Thu, 18 Aug 2005 11:06:13 +0200 (MEST)
From: Matthias Klose <doko@cs.tu-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17156.20357.670612.740584@gargle.gargle.HOWL>
Date: Thu, 18 Aug 2005 11:06:13 +0200
To: Moritz Bunkus <moritz@bunkus.org>, 275023-done@bugs.debian.org
Subject: Re: Bug#275023: g++-3.4: valgrind reports vectors don't free their memory
In-Reply-To: <[🔎] 200508160945.03393.moritz@bunkus.org>
References: <87d5rjgu5k.fsf@debian.org>
<[🔎] 200508160945.03393.moritz@bunkus.org>
X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid
X-Virus-Scanned: by amavisd-new at cs.tu-berlin.de
Delivered-To: 275023-done@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
Moritz Bunkus writes:
> Hey,
>
> sorry for not responding for such a long time. I've upgraded to valgrind
> 3.0 and g++ 3.4.5, and valgrind does not report these leaks anymore. So
> the issue's been solved.
thanks for the feedback.
closing the report.
Reply to: