http://bugzilla.opensuse.org/show_bug.cgi?id=1092054
Bug ID: 1092054
Summary: valgrind misreports number of allocations and size of
memory allocated
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.0
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Development
Assignee: bnc-team-screening@forge.provo.novell.com
Reporter: drankinatty@suddenlinkmail.com
QA Contact: qa-bugs@suse.de
Found By: ---
Blocker: ---
Beginning with leap 15 and gcc 7.3, valgrind misreports the number of
allocations and the size of memory allocated. This gets exponentially worse and
the number of actual allocations in your code increases. A simple example
discloses the problem:
$ cat vgtest2.c
#include
#include
int main (void) {
int *a = malloc (sizeof *a);
*a = 5;
printf ("a: %d\n", *a);
free (a);
}
Above there is a single allocation of 4-bytes which is correctly reported on
all versions of openSuSE before Leap 15. However, beginning with Leap 15, the
number of allocations is reported as 2 and the number of bytes allocated as
1028 (1024 more than actual)
E.g. compile with -O0 to insure nothing is optimized away and dump to assembly
to confirm the call to malloc:
$ gcc -S -masm=intel -O0 -o vgtest2.asm vgtest2.c
$ cat vgtest2.asm
.file "vgtest2.c"
.intel_syntax noprefix
.text
.section .rodata
.LC0:
.string "a: %d\n"
.text
.globl main
.type main, @function
main:
.LFB5:
.cfi_startproc
push rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
mov rbp, rsp
.cfi_def_cfa_register 6
sub rsp, 16
mov edi, 4 ; <= 4-bytes requested
call malloc ; <= 1 call to malloc
mov QWORD PTR [rbp-8], rax
mov rax, QWORD PTR [rbp-8]
mov DWORD PTR [rax], 5
mov rax, QWORD PTR [rbp-8]
mov eax, DWORD PTR [rax]
mov esi, eax
mov edi, OFFSET FLAT:.LC0
mov eax, 0
call printf
mov rax, QWORD PTR [rbp-8]
mov rdi, rax
call free
mov eax, 0
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE5:
.size main, .-main
.ident "GCC: (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision
258812]"
.section .note.GNU-stack,"",@progbits
Now compile and test with valgrind. All prior releases report 1-allocation
4-bytes allocated, but with Leap 15 there are 2-allocations, 1028-bytes
allocated, e.g.
$ gcc -std=gnu11 -O0 -o bin/vgtest2 vgtest2.c
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)
The incorrect reporting by valgrind detracts from its value as a validation
tool and compromises its effectiveness as a teaching tool. E.g.
"You can look at valgrind to confirm you have freed all memory you have
allocated, but you can't rely on the amount of memory valgrind shows allocated
-- that doesn't work right anymore..."
I don't know whether this belongs to gcc, to kde or where, but to date, nobody
has taken responsibility for it and it is still broken. The one thing that is
clear is valgrind has always correctly reported the number of allocations and
the amount of memory allocated on all prior openSuSE releases, but no longer
does. It has worked correctly for years and is now broken -- that is a bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
