[Valgrind-users] Valgrind musl 1.2.2 bug

[<k.m...@gm...>]

Hello valgrind community!

This is my first message ever to this mailing list.

I am currently experiencing a weird bug in valgrind, where it
mistakenly does not recognize malloc/free/realloc function and also produces
weird warnings. But only on musl linux x86_64 version 1.2.2

Consider this simple C program:

#include "stdio.h"
#include "stdlib.h"

int main()
{
        char *mem = malloc(123);
        *mem = 5;
        *(mem+1) = 5;
        *(mem+2) = 5;

        mem = realloc(mem, 400);
        *(mem+1) = 5;
        *(mem+2) = 5;
        free(mem);
        return 0;
}

As you can see there can't be any bugs in this code, everything is
within bounds.

However when I run
$ valgrind ./a.out
==486== Memcheck, a memory error detector
==486== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==486== Using Valgrind-3.18.0.GIT and LibVEX; rerun with -h for copyright info
==486== Command: ./a.out
==486==
==486== Invalid free() / delete / delete[] / realloc()
==486==    at 0x48C589F: realloc (vg_replace_malloc.c:1192)
==486==    by 0x109298: main (in /root/test/a.out)
==486==  Address 0x48baf80 is in a rw- mapped file
/usr/local/libexec/valgrind/vgpreload_core-amd64-linux.so segment
==486==
==486== Invalid write of size 1
==486==    at 0x1092A5: main (in /root/test/a.out)
==486==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
==486==
==486==
==486== Process terminating with default action of signal 11 (SIGSEGV)
==486==  Access not within mapped region at address 0x1
==486==    at 0x1092A5: main (in /root/test/a.out)
==486==  If you believe this happened as a result of a stack
==486==  overflow in your program's main thread (unlikely but
==486==  possible), you can try to increase the size of the
==486==  main thread stack using the --main-stacksize= flag.
==486==  The main thread stack size used in this run was 8388608.
==486==
==486== HEAP SUMMARY:
==486==     in use at exit: 0 bytes in 0 blocks
==486==   total heap usage: 1 allocs, 1 frees, 400 bytes allocated
==486==
==486== All heap blocks were freed -- no leaks are possible
==486==
==486== For lists of detected and suppressed errors, rerun with: -s
==486== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault

This happens. -----------------------------

musl version is 1.2.2 from KISS linux
https://github.com/kiss-community/repo-main/tree/master/core/musl

I built valgrind myself from source without any special
configuration. I also tested it on Valgrind-3.16.0.RC1 940ec1ca6 and same
results.

$ autogen.sh
$ configure
$ make install

OK. Now when I use the musl 1.2.1 version
this should be the correct output from valgrind.

==918== Memcheck, a memory error detector
==918== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==918== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==918== Command: ./a.out
==918==
==918==
==918== HEAP SUMMARY:
==918==     in use at exit: 468 bytes in 4 blocks
==918==   total heap usage: 7 allocs, 3 frees, 1,031 bytes allocated
==918==
==918== LEAK SUMMARY:
==918==    definitely lost: 0 bytes in 0 blocks
==918==    indirectly lost: 0 bytes in 0 blocks
==918==      possibly lost: 0 bytes in 0 blocks
==918==    still reachable: 468 bytes in 4 blocks
==918==         suppressed: 0 bytes in 0 blocks
==918== Rerun with --leak-check=full to see details of leaked memory
==918==
==918== For lists of detected and suppressed errors, rerun with: -s
==918== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Is this a bug in musl or a bug on valgrind side?

Regards,
Kyryl