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
