On 1.4.2018 00:05, David C. Rankin wrote:
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.
Greetings, by default valgrind is using memcheck (same as `valgrind --tool=memcheck`), but there are better tools for profiling - for example, massif (`valgrind --tool=massif`). To measure heap memory consumption:
% valgrind --tool=massif --threshold=0 ./a.out
To view memory consumption:
% ms_print --threshold=0 massif.out*
This is what your example produces:
[...] 97.92% (1,034B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc. ->96.97% (1,024B) 0x4E9CB9B: _IO_file_doallocate (in /usr/lib/libc-2.26.so) | ->96.97% (1,024B) 0x4EAB5F7: _IO_doallocbuf (in /usr/lib/libc-2.26.so) | ->96.97% (1,024B) 0x4EAA876: _IO_file_overflow@@GLIBC_2.2.5 (in /usr/lib/libc-2.26.so) | ->96.97% (1,024B) 0x4EA98E5: _IO_file_xsputn@@GLIBC_2.2.5 (in /usr/lib/libc-2.26.so) | ->96.97% (1,024B) 0x4E7CF7A: vfprintf (in /usr/lib/libc-2.26.so) | ->96.97% (1,024B) 0x4E859D4: printf (in /usr/lib/libc-2.26.so) | ->96.97% (1,024B) 0x1087A4: main (in [...]) | ->00.95% (10B) 0x10873F: main (in [...]) [...]
This is what your example produces, but with a removed `printf()` call:
[...] 41.67% (10B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc. ->41.67% (10B) 0x1086EF: main (in [...]) [...]
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. -- Regards, Oleksii Vilchanskyi PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338 *** All the world's a pipeline, And all the men and women merely instructions.