Mailinglist Archive: opensuse-factory (536 mails)

< Previous Next >
Re: [opensuse-factory] Leap 15 - valgrind misreports the number of allocations and amount of memory allocated

On Monday 2018-05-07 11:56, David C. Rankin wrote:

I have filed

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
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

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
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >