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 <stdio.h>
> #include <stdlib.h>
>
> #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.
Attachment:
signature.asc
Description: OpenPGP digital signature
