[Bug 256211] valgrind shows one leak every time

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 01 Jun 2021 06:52:17 +0000

--- Comment #1 from Paul Floyd <pjfloyd_at_wanadoo.fr> ---
There is no problem here. If you run Valgrind with -s you will get

--4534-- used_suppression:      1 MEMCHECK-LIBC-REACHABLE
/usr/local/libexec/valgrind/default.supp:589 suppressed: 4,096 bytes in 1

That means that the 4k still in use is known and suppressed by the system
suppressions file

If you run Valgrind with --defaut-suppressions=no  then you will see

==4537== 4,096 bytes in 1 blocks are still reachable in loss record 1 of 1
==4537==    at 0x484C8A4: malloc (in
==4537==    by 0x4974AA3: ??? (in /lib/libc.so.7)
==4537==    by 0x4987278: ??? (in /lib/libc.so.7)
==4537==    by 0x497B012: ??? (in /lib/libc.so.7)
==4537==    by 0x497AD89: vfprintf_l (in /lib/libc.so.7)
==4537==    by 0x4975AF3: printf (in /lib/libc.so.7)
==4537==    by 0x201D48: main (example.c:16)

In theory it would be possible to remove this suppression by modifying libc. On
Linux, GNU libc has a __libc_freeres function, In normal use, Linux GNU libc
applications do not call this function. Valgrind does some fiddling on guest
application termination and _does_ call thisa function. The advantages of using
freeres over suppressions are that
a) it is slighlty cleaner
b) it is less sensitive (suppressions tend to change over time and libc could
add more uses of reachable memory).

If this really bothers you, open a bugzilla item for libc to add a freeres
function and then I can add that to Valgrind.

You are receiving this mail because:
You are the assignee for the bug.
Received on Tue Jun 01 2021 - 06:52:17 UTC

Original text of this message