Your message dated Thu, 18 Aug 2005 11:06:13 +0200
with message-id <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED] Tue Oct 05 07:50:47 2004
Return-path: <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
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: <[EMAIL PROTECTED]>
X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at bunkus.org
X-Virus-Scanned: by amavisd-new at bunkus.org
Delivered-To: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] Thu Aug 18 02:06:18 2005
Return-path: <[EMAIL PROTECTED]>
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 ([EMAIL PROTECTED] [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 [EMAIL PROTECTED])
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 <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 11:06:13 +0200
To: Moritz Bunkus <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Bug#275023: g++-3.4: valgrind reports vectors don't free their
memory
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
