https://bugs.kde.org/show_bug.cgi?id=435441
Bug ID: 435441
Summary: valgrind fails to interpose malloc on musl 1.2.2 due
to weak symbol name and no libc soname
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: mfor...@mforney.org
Target Milestone: ---
SUMMARY
Starting with musl 1.2.2, malloc is a weak symbol in libc.so. Also, musl's
libc.so is built without any soname (though Alpine Linux, a popular musl-based
distribution, builds it with -Wl,-soname,libc.musl-x86_64.so.1). The
combination of these two seems to prevent valgrind from replacing malloc,
though free is still replaced correctly.
STEPS TO REPRODUCE
1. Download and extract a musl toolchain from
http://musl.cc/x86_64-linux-musl-cross.tgz
2. Install a /lib/ld-musl-x86_64.so.1 symlink with ln -s
/path/to/x86_64-linux-musl-cross/x86_64-linux-musl/libc.so
/lib/ld-musl-x86_64.so.1
3. Build valgrind with ./configure --host=x86_64-linux-musl
CC=/path/to/x86_64-linux-musl-cross/bin/x86_64-linux-musl-gcc.
4. Compile the following C program with x86_64-linux-musl-gcc:
#include <stdlib.h>
int main(void) { free(malloc(32)); }
5. Run the program with ./vg-in-place ./a.out
>From a musl-based system with valgrind installed, you can skip steps 2 and 3.
OBSERVED RESULT
valgrind prints the following error:
==21034== Invalid free() / delete / delete[] / realloc()
==21034== at 0x4A0CA4B: free (vg_replace_malloc.c:538)
==21034== by 0x48007DA: main (in /tmp/a.out)
==21034== Address 0x4a01d10 is in a rw- mapped file /tmp/a.out segment
==21034==
==21034==
==21034== HEAP SUMMARY:
==21034== in use at exit: 0 bytes in 0 blocks
==21034== total heap usage: 0 allocs, 1 frees, 0 bytes allocated
This seems to because malloc did not get replaced, so valgrind was unaware of
the allocation.
EXPECTED RESULT
valgrind should not print any errors, and detect 1 alloc and 1 free.
SOFTWARE/OS VERSIONS
Linux, musl 1.2.2
ADDITIONAL INFORMATION
Passing --soname-synonyms=somalloc=NONE or rebuilding musl libc.so with a
strong malloc symbol both seem to solve the problem. However, the weak malloc
symbol is needed in order to prevent __libc_malloc from clashing with a malloc
linked by the application.
musl developers suspect that the problem is due to something valgrind is doing
with weak symbols.
--
You are receiving this mail because:
You are watching all bug changes.
