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.