Valgrind musl 1.2.2 bug

[email protected](Kyryl Melekhin)
Newsgroups gmane.comp.debugging.valgrind
Message-ID <60872132.s+lJePUrZWOgnnfC%[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.