[arch-general] valgrind 3.13.0-6 exclusions broken again

[Oleksii Vilchanskyi]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20180401/f0c0bd43/attachment.asc>