Re: [arch-general] valgrind 3.13.0-6 exclusions broken again
On 04/07/2018 06:58 AM, Levente Polyak wrote: > On April 7, 2018 6:18:39 AM GMT+02:00, "David C. Rankin" > 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.
Re: [arch-general] valgrind 3.13.0-6 exclusions broken again
On April 7, 2018 6:18:39 AM GMT+02:00, "David C. Rankin" 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
Re: [arch-general] valgrind 3.13.0-6 exclusions broken again
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
> #include
>
> 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.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] valgrind 3.13.0-6 exclusions broken again
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
#include
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.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] valgrind 3.13.0-6 exclusions broken again
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.
signature.asc
Description: OpenPGP digital signature
