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