[opensuse-factory] Leap 15 - valgrind misreports the number of allocations and amount of memory allocated
All, I have filed https://bugzilla.opensuse.org/show_bug.cgi?id=1092054 against valgrind misreporting the number of allocations, and size of memory allocated. valgrind has correctly reported in all prior openSuSE releases, but not reports additional allocations (which gets exponentially worse as the number of allocations in your code increases) If you have any additional insight, please add it to the bug. Simple test case: #include <stdio.h> #include <stdlib.h> int main (void) { int *a = malloc (sizeof *a); *a = 5; printf ("a: %d\n", *a); free (a); } Compile *without* optimization, e.g. $ gcc -std=gnu11 -O0 -o bin/vgtest2 vgtest2.c Check with valgrind: $ valgrind ./bin/vgtest2 ==3018== Memcheck, a memory error detector ==3018== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3018== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==3018== Command: ./bin/vgtest2 ==3018== a: 5 ==3018== ==3018== HEAP SUMMARY: ==3018== in use at exit: 0 bytes in 0 blocks ==3018== total heap usage: 2 allocs, 2 frees, 1,028 bytes allocated ==3018== ==3018== All heap blocks were freed -- no leaks are possible ==3018== ==3018== For counts of detected and suppressed errors, rerun with: -v ==3018== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) All prior openSuSE release correctly show 1-allocation, 4-bytes allocated. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sonntag, 6. Mai 2018 01:56:14 CEST David C. Rankin wrote:
All,
I have filed https://bugzilla.opensuse.org/show_bug.cgi?id=1092054 against valgrind misreporting the number of allocations, and size of memory allocated. valgrind has correctly reported in all prior openSuSE releases, but not reports additional allocations (which gets exponentially worse as the number of allocations in your code increases)
The valgrind report is completely correct. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On 05/05/2018 07:51 PM, Stefan Brüns wrote:
On Sonntag, 6. Mai 2018 01:56:14 CEST David C. Rankin wrote:
All,
I have filed https://bugzilla.opensuse.org/show_bug.cgi?id=1092054 against valgrind misreporting the number of allocations, and size of memory allocated. valgrind has correctly reported in all prior openSuSE releases, but not reports additional allocations (which gets exponentially worse as the number of allocations in your code increases)
The valgrind report is completely correct.
Regards,
Stefan
If it is reporting 1028 bytes allocated for 1-integer, it is most certainly NOT correct. Are you saying it was incorrect in all prior releases reporing 4-bytes per-int instead of 1028-bytes per-int? The two reportings from Leap 42.3 and Leap 15 are completely different -- which one are you saying is right? It's a binary, mutually exclusive proposition... I note you cite no reference and no prior comparison in making your assertion that the valgrind output in Leap 15 is correct. What the problem points to is a missing or wrong exclusion file for gcc 7.3. Ignoring the problem, or just saying "it's correct", won't fix it. -- David C. Rankin, J.D.,P.E.
On Monday 2018-05-07 05:20, David C. Rankin wrote:
I have filed https://bugzilla.opensuse.org/show_bug.cgi?id=1092054 against
The valgrind report is completely correct.
If it is reporting 1028 bytes allocated for 1-integer, it is most certainly NOT correct.
You can drop the act - you are doing more than "just" allocating one puny integer buffer. *Besides* the printf which was pointed out to you in bugzilla, given just the right laboratory conditions (ulimit -v somethingsomething), I can make your 5-liner program exhibit undefined behavior, at which point a program is allowed to do anything — that, by definition, can include allocations. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/07/2018 12:56 AM, Jan Engelhardt wrote:
On Monday 2018-05-07 05:20, David C. Rankin wrote:
I have filed https://bugzilla.opensuse.org/show_bug.cgi?id=1092054 against
The valgrind report is completely correct.
If it is reporting 1028 bytes allocated for 1-integer, it is most certainly NOT correct.
You can drop the act - you are doing more than "just" allocating one puny integer buffer. *Besides* the printf which was pointed out to you in bugzilla, given just the right laboratory conditions (ulimit -v somethingsomething), I can make your 5-liner program exhibit undefined behavior, at which point a program is allowed to do anything — that, by definition, can include allocations.
There is no act Jan, frustration perhaps at people dancing around the issue of: All prior releases, valgind reports: 1-allocation, 4-bytes -- which is 100% correct. Now on leap 15, the same code reports 2-allocations, 1028-bytes -- which is not correct. What does your comment about a hypothetical ulimit change have to do with this current valgrind issue? SuSE, the openSuSE releases from the beginning through Leap 42.3 all report: 1-allocation, 4-bytes -- which is 100% correct. Leap 15 reports 2-allocations, 1028-bytes -- which is not correct. If you are saying, "Well, nobody is going to fix it, so valgind may report a few extra allocations and the bytes reported as allocated will no longer have any relation to the allocation the user makes." Then that fine, we will just have a degraded and much less useful valgrind that have ever existed before. One of the 2 differing behaviors is wrong, and it doesn't take a rocket-scientist to tell which one (although I am qualified in that regard as well) Have you tested on both Leap 42.3 and the Leap 15?? If you have, then Why does valgrid give different output between them. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2018-05-07 at 04:56 -0500, David C. Rankin wrote:
SuSE, the openSuSE releases from the beginning through Leap 42.3 all report:
There never ever was a openSuSE release - EVER! since the introduction of the name openSUSE - it was spelled just like that: openSUSE. And prior to that, it was SUSE Linux (up to 10.1) You've been around long enough to know this. Cheers Dominique
Hi, On Mon, May 7, 2018 at 12:56 PM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote: (snip)
All prior releases, valgind reports:
1-allocation, 4-bytes -- which is 100% correct.
Now on leap 15, the same code reports
2-allocations, 1028-bytes -- which is not correct.
I wonder whether this bug report should be reported upstream as per http://valgrind.org/support/bug_reports.html rather than on the openSUSE mailing lists? While I'm sure that there are a lot of people that have great insights on valgrind usage here, the bug reporting channel is different. Thanks, Robert -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2018-05-07 11:56, David C. Rankin wrote:
I have filed https://bugzilla.opensuse.org/show_bug.cgi?id=1092054 against
You can drop the act - you are doing more than "just" allocating one puny integer buffer. *Besides* the printf which was pointed out to you in bugzilla, given just the right laboratory conditions (ulimit -v somethingsomething), I can make your 5-liner program exhibit undefined behavior, at which point a program is allowed to do anything — that, by definition, can include allocations.
There is no act Jan, frustration perhaps at people dancing around the issue of: All prior releases, valgind reports: 1-allocation, 4-bytes -- which is 100% correct. Now on leap 15, the same code reports 2-allocations, 1028-bytes -- which is not correct.
Why is it so hard for you to accept that valgrind is merely observing the internal behavior of printf. It might not have appeared in previous releases, now it does, because now glibc does an allocation and it did not previously. Big deal. Get over it. Breakpoint 2, __GI___libc_malloc (bytes=1024) at malloc.c:3028 3028 { #1 0x00007ffff7a8842c in __GI__IO_file_doallocate (fp=0x7ffff7dd2760 <_IO_2_1_stdout_>) at filedoalloc.c:101 101 p = malloc (size); #2 0x00007ffff7a973e9 in __GI__IO_doallocbuf (fp=fp@entry=0x7ffff7dd2760 <_IO_2_1_stdout_>) at genops.c:365 365 if (_IO_DOALLOCATE (fp) != EOF) #3 0x00007ffff7a95fa8 in _IO_new_file_overflow (f=0x7ffff7dd2760 <_IO_2_1_stdout_>, ch=-1) at fileops.c:759 759 _IO_doallocbuf (f); #4 0x00007ffff7a9504f in _IO_new_file_xsputn (f=0x7ffff7dd2760 <_IO_2_1_stdout_>, data=<optimized out>, n=2) at fileops.c:1266 1266 if (_IO_OVERFLOW (f, EOF) == EOF) #5 0x00007ffff7a6997f in _IO_vfprintf_internal (s=0x7ffff7dd2760 <_IO_2_1_stdout_>, format=0x400614 "%d\n", ap=ap@entry=0x7fffffffdcb0) at vfprintf.c:1642 1642 process_arg (((struct printf_spec *) NULL)); #6 0x00007ffff7a70ed6 in __printf (format=<optimized out>) at printf.c:33 33 done = vfprintf (stdout, format, arg); #7 0x000000000040057e in main () at z.c:7 7 printf("%d\n", *a);
What does your comment about a hypothetical ulimit change have to do with this current valgrind issue?
Because it's a (potential) bug in your program, and depending on the ulimit setting and moon phase, it could trigger. I am just mentioning it as option 3. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
David, On Mon, 07 May 2018, 11:56:36 +0200, David C. Rankin wrote:
[...] All prior releases, valgind reports:
1-allocation, 4-bytes -- which is 100% correct.
Now on leap 15, the same code reports
2-allocations, 1028-bytes -- which is not correct.
did you try using the "--leak-check=full" flag? Maybe the runtime system around your main function now allocates some memory, which it didn't before. If that's the case, you should see some indication referring to some other file than yours. HTH, cheers. l8er manfred
participants (6)
-
David C. Rankin -
Dominique Leuenberger / DimStar -
Jan Engelhardt -
Manfred Hollstein -
Robert Munteanu -
Stefan Brüns