Summary: | valgrind fails to interpose malloc on musl 1.2.2 due to weak symbol name and no libc soname | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Michael Forney <mforney> |
Component: | general | Assignee: | Paul Floyd <pjfloyd> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | nsz.foo, pjfloyd, sam, tom |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Patch to handle weak symbols as global |
Description
Michael Forney
2021-04-06 23:03:25 UTC
Surely it's just down to the fact that we don't intercept symbols with that soname, as you've proved by removing the soname match with that switch? Does --soname-synonyms=somalloc=libc.musl-x86_64.so.1 also make it work? With --soname-synonyms=somalloc=libc.musl-x86_64.so.1 the warnings go away, but this is because it makes valgrind unable to track free as well as malloc: ==31116== HEAP SUMMARY: ==31116== in use at exit: 0 bytes in 0 blocks ==31116== total heap usage: 0 allocs, 0 frees, 0 bytes allocated To be clear, by default musl libc.so does not have a soname. It is only on Alpine Linux that it is built with a soname of libc.musl-x86_64.so.1. if the malloc symbol is changed to be strong in libc.so then the test passes. in a shared library, defined symbols with weak binding should be treated exactly the same way as symbols with global binding, so valgrind is definitely doing something wrong. historically glibc had bugs where the dynamic linker treated weak symbols specially, but that was 20 years ago (see LD_DYNAMIC_WEAK in the ld.so manual). it is not clear why valgrind cares about the soname, i think the malloc symbol should be interposed independently of the soname of the defining library. Created attachment 143217 [details]
Patch to handle weak symbols as global
Here's a patch that fixes the issue for me by setting *is_global_out=True for STB_WEAK symbols in addition to STB_GLOBAL.
Have you tested this on other platforms? My concern with this is that it is an essential piece of code. I've seen lots of problems with pthread functions across Linux/FreeBSD/Solaris/Musl with various combinations of stubs and weak symbols. No new failures on FreeBSD. Thanks, I was wondering why I got spurious failures on fclose() w/ Gentoo+musl. This patch sorts that. Pushed the change. I want to check that there is no falllout before closing this. commit 5a6f1c1322d742308aaa4b3c1d937942b3de6c5a (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd <pjfloyd@wanadoo.fr> Date: Mon Jan 23 09:05:50 2023 +0100 Bug 435441 - valgrind fails to interpose malloc on musl 1.2.2 due to weak symbol name and no libc soname Patch by Michael Forney <mforney@mforney.org> I didn't see any fallout. |