[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <OF11E7837C.B1724FC1-ONC12584E7.0035C6F0-C12584E7.003C91B1@avm.de>
Date: Mon, 6 Jan 2020 12:01:34 +0100
From: d.dorau@....de
To: musl@...ts.openwall.com
Subject: Issue with musl and valgrind
Hello and a happy new year!
I'm looking for some help/advice regarding the use of valgrind with musl.
In my attempts to use valgrind with musl I ran into a reproducible crash.
I found others
experienced this earlier as well, but with no apparent solution:
https://forum.archive.openwrt.org/viewtopic.php?id=70169
==3915== Invalid read of size 4
==3915== at 0x48C3154: free (in
/usr/lib/valgrind/vgpreload_memcheck-mips32-linux.so)
==3915== by 0x4088C04: ??? (in /lib/libc.so)
==3915== Address is not stack'd, malloc'd or (recently) free'd
I did some debugging and came to a plausible reason, and with a quick
hack I could get it to run.
My findings are that when musl loads vgpreload_memcheck-mips32-linux.so,
malloc/free are replaced by the implementation provided from valgrind, as
expected.
The free() call that leads to the crash originates from musl's
dynlink.c:782 in
map_library().
The crash in valgrind's vgpreload_memcheck-mips32-linux.so is located in
coregrind/m_replacemalloc/vg_replace_malloc.c:184 as part of the macro
DO_INIT
static int init_done;
#define DO_INIT if (UNLIKELY(!init_done)) init()
[...]
#define FREE(soname, fnname, vg_replacement) \
\
void VG_REPLACE_FUNCTION_EZU(10050,soname,fnname) (void *p); \
void VG_REPLACE_FUNCTION_EZU(10050,soname,fnname) (void *p) \
{ \
DO_INIT; \
MALLOC_TRACE(#fnname "(%p)\n", p ); \
if (p == NULL) \
return; \
(void)VALGRIND_NON_SIMD_CALL1( info.tl_##vg_replacement, p ); \
}
that is called in the free function provided by valgrind.
Calculating back the crash address 0x1e0d8 from the example above leads to
the
address of the variable "init_done" of the valgrind code in the ELF file
itself!
My interpretation is that although the relocation of the new free function
has
apprently been done, the variables (and maybe other called functions) used
*inside*
the valgrind library have not been relocated yet, so that their addresses
still
point to the bare address in the ELF file. (I hope the explanation makes
sense.)
I could avoid the crash by patching musl so that dynlink.c always calls
musl's
own malloc/free function (by renaming and an additional wrapper for the
exported
symbols).
Since I don't have in-depth knowledge about the inner workings of musl's
shared
library loader, I'm now looking for advice on how to solve this issue.
At first glance the fact that functions inside the loaded library are
called before
all relocations are done looks problematic to me.
Assuming this would be solved, wouldn't it be desirable to ensure that
malloc/free
calls inside musl won't be replaced by external libraries so that we don't
get
stale allocations left from the old allocator?
Best regards,
Daniel
--
AVM Audiovisuelles Marketing und Computersysteme GmbH
Alt-Moabit 95, 10559 Berlin
HRB 23075 AG Charlottenburg
Geschäftsführer: Johannes Nill
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
