Discussion:
valgrind 3.13.0-6 exclusions broken again
(too old to reply)
David C. Rankin
2018-03-31 22:05:12 UTC
Permalink
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.
Oleksii Vilchanskyi via arch-general
2018-04-01 01:56:30 UTC
Permalink
Post by David C. Rankin
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
#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== 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`).
Post by David C. Rankin
% valgrind --tool=massif --threshold=0 ./a.out
% ms_print --threshold=0 massif.out*
[...]
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) 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 [...])
[...]
[...]
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.
David C. Rankin
2018-04-02 00:43:15 UTC
Permalink
Post by Oleksii Vilchanskyi via arch-general
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.
David C. Rankin
2018-04-07 04:18:39 UTC
Permalink
Post by David C. Rankin
Now allocating for 1 integer reports 2 allocations and 1,028 bytes
#include <stdio.h>
#include <stdlib.h>
int main (void) {
int *a = malloc (sizeof *a);
*a = 5;
printf ("a: %d\n", *a);
free (a);
}
$ 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== 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.
Levente Polyak via arch-general
2018-04-07 11:58:07 UTC
Permalink
Post by David C. Rankin
Post by David C. Rankin
I was looking for confirmation of the bug and whether the devs want
it
Post by David C. Rankin
filed here to track or to not waste time filing with Arch and just
file
Post by David C. Rankin
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
David C. Rankin
2018-04-08 04:14:01 UTC
Permalink
Post by Levente Polyak via arch-general
Post by David C. Rankin
Post by David C. Rankin
I was looking for confirmation of the bug and whether the devs want
it
Post by David C. Rankin
filed here to track or to not waste time filing with Arch and just
file
Post by David C. Rankin
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.
Loading...