[arch-general] valgrind 3.13.0-6 exclusions broken again
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. -- David C. Rankin, J.D.,P.E.
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.
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.
On 04/01/2018 07:43 PM, David C. Rankin wrote:
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?
I suspect this is a gcc-libs/valgrind issue, I updated https://bugs.archlinux.org/task/49681 with the information. -- David C. Rankin, J.D.,P.E.
On April 7, 2018 6:18:39 AM GMT+02:00, "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
On 04/01/2018 07:43 PM, David C. Rankin wrote:
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?
I suspect this is a gcc-libs/valgrind issue, I updated https://bugs.archlinux.org/task/49681 with the information.
Please bring this issue upstream, where it could actually be fixed. Cheers, Levente
On 04/07/2018 06:58 AM, Levente Polyak wrote:
On April 7, 2018 6:18:39 AM GMT+02:00, "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
On 04/01/2018 07:43 PM, David C. Rankin wrote:
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?
I suspect this is a gcc-libs/valgrind issue, I updated https://bugs.archlinux.org/task/49681 with the information.
Please bring this issue upstream, where it could actually be fixed.
Cheers, Levente
Done: https://bugs.kde.org/show_bug.cgi?id=392855 -- David C. Rankin, J.D.,P.E.
participants (3)
-
David C. Rankin
-
Levente Polyak
-
Oleksii Vilchanskyi