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

Reply via email to