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 <stdio.h>
#include <stdlib.h>

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.