Devs,
valgrind is reporting more memory allocated than actual. This occurred a
couple of months back as well, was resolved, and is now apparently back again?
I don't know if this is a regression, but for each allocation, an additional
allocation is reported and up to 2^10 additional bytes are reported. Here is a
short example where 1 allocation of 10-bytes is made:
#include
#include
#define NVAL 10
int main (void) {
char *a = calloc (NVAL, sizeof *a);
if (!a) {
perror ("calloc - a");
return 1;
}
/* fill with [a-i] and output */
for (int i = 0; i < NVAL - 1; i++)
a[i] = 'a' + i;
printf ("a: '%s' (1 alloc - %lu bytes)\n", a, sizeof *a * NVAL);
free (a);
}
However, valgrind reports 2 allocations and 1034-bytes (10 + 2^10), e.g.
$ valgrind ./bin/valgrindchk
==1134== Memcheck, a memory error detector
==1134== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1134== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1134== Command: ./bin/valgrindchk
==1134==
a: 'abcdefghi' (1 alloc - 10 bytes)
==1134==
==1134== HEAP SUMMARY:
==1134== in use at exit: 0 bytes in 0 blocks
==1134== total heap usage: 2 allocs, 2 frees, 1,034 bytes allocated
==1134==
==1134== All heap blocks were freed -- no leaks are possible
==1134==
==1134== For counts of detected and suppressed errors, rerun with: -v
==1134== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I'm not even using the --atavistic option...
If someone can confirm, and let me know if a bug is warranted and I'll
happily file one. If I recall correctly, this would be an upstream issue, I
don't think Arch messes with the exclusions in any way. Let me know what you
think.
--
David C. Rankin, J.D.,P.E.