On 3/31/2018 8:56 PM, Oleksii Vilchanskyi wrote:
> So, that's glibc which allocates additional memory for `printf()`, and
> there's nothing wrong with valgrind. Quite the contrary - valgrind can
> be a very sharp Swiss knife.
>
Yes, yes, thanks, I know where the memory is being allocated. This is a
regression somewhere causing valgrind to no longer mask system
allocations in its default reporting.
There are, and have always been, proper exclusion files that mask the
memory allocated behind the scenes for standard stream openings, etc..
valgrind was working correctly just a few days ago and now either a gcc,
kernel or valgrind change has caused a regression so that the exclusions
that mask memory allocated by the system are no longer working correctly.
Now allocating for 1 integer reports 2 allocations and 1,028 bytes
instead of 1 allocation and 4 bytes as it did a couple of days ago, e.g.:
#include <stdio.h>
#include <stdlib.h>
int main (void) {
int *a = malloc (sizeof *a);
*a = 5;
printf ("a: %d\n", *a);
free (a);
}
The valgrind output:
$ valgrind ./bin/vgtest2
==10415== Memcheck, a memory error detector
==10415== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==10415== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==10415== Command: ./bin/vgtest2
==10415==
a: 5
==10415==
==10415== HEAP SUMMARY:
==10415== in use at exit: 0 bytes in 0 blocks
==10415== total heap usage: 2 allocs, 2 frees, 1,028 bytes allocated
==10415==
==10415== All heap blocks were freed -- no leaks are possible
==10415==
==10415== For counts of detected and suppressed errors, rerun with: -v
==10415== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I was looking for confirmation of the bug and whether the devs want it
filed here to track or to not waste time filing with Arch and just file
upstream?
--
David C. Rankin, J.D.,P.E.
Attachment:
signature.asc
Description: OpenPGP digital signature
