On Sat, 9 Jan 2016 14:12:58 +0000 Alessandro Ghedini <[email protected]>
wrote:
> On Fri, Oct 23, 2015 at 03:25:53PM +0200, Mathieu Malaterre wrote:
> > Package: valgrind
> > Version: 1:3.11.0-1
> > Tags: upstream
> >
> > Seems like gcc 5 is doing something funky
> > (/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21):
> >
> > ==3674==
> > ==3674== HEAP SUMMARY:
> > ==3674== in use at exit: 72,704 bytes in 1 blocks
> > ==3674== total heap usage: 306,736 allocs, 306,735 frees, 22,184,464
> > bytes allocated
> > ==3674==
> > ==3674== 72,704 bytes in 1 blocks are still reachable in loss
record 1 of 1
> > ==3674== at 0x4C28C4F: malloc (vg_replace_malloc.c:299)
> > ==3674== by 0x72ED11F: pool (eh_alloc.cc:117)
> > ==3674== by 0x72ED11F: __static_initialization_and_destruction_0
> > (eh_alloc.cc:244)
> > ==3674== by 0x72ED11F: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:307)
> > ==3674== by 0x400EA09: call_init.part.0 (dl-init.c:78)
> > ==3674== by 0x400EAF2: call_init (dl-init.c:36)
> > ==3674== by 0x400EAF2: _dl_init (dl-init.c:126)
> > ==3674== by 0x40011C9: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
> > ==3674== by 0x1: ???
> > ==3674== by 0xFFF00049A: ???
> > ==3674== by 0xFFF0004A9: ???
> > ==3674==
> > ==3674== LEAK SUMMARY:
> > ==3674== definitely lost: 0 bytes in 0 blocks
> > ==3674== indirectly lost: 0 bytes in 0 blocks
> > ==3674== possibly lost: 0 bytes in 0 blocks
> > ==3674== still reachable: 72,704 bytes in 1 blocks
> > ==3674== suppressed: 0 bytes in 0 blocks
>
> This is a false positive and should be suppressed. It may take me
some time to
> look into this though, so if you want to provide a patch (to the
debian.supp
> file) feel free to do so.
1. This never was a false positive (Valgrind neither imagined an
inexistent call to malloc nor missed an existing call to free).
2. It also should not be suppressed.
3. This was fixed decades ago. 2002 according to git. Valgrind should
call __libc_freeres() so that memory like this gets freed.
A+
Paul