Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Jan 2020 12:01:34 +0100
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:

==3915== Invalid read of size 4
==3915==    at 0x48C3154: free (in 
==3915==    by 0x4088C04: ??? (in /lib/
==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,
malloc/free are replaced by the implementation provided from valgrind, as 

The free() call that leads to the crash originates from musl's 
dynlink.c:782 in

The crash in valgrind's is located in 
coregrind/m_replacemalloc/vg_replace_malloc.c:184 as part of the macro 

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 
address of the variable "init_done" of the valgrind code in the ELF file 

My interpretation is that although the relocation of the new free function 
apprently been done, the variables (and maybe other called functions) used 
the valgrind library have not been relocated yet, so that their addresses 
point to the bare address in the ELF file. (I hope the explanation makes 

I could avoid the crash by patching musl so that dynlink.c always calls 
own malloc/free function (by renaming and an additional wrapper for the 

Since I don't have in-depth knowledge about the inner workings of musl's 
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 
calls inside musl won't be replaced by external libraries so that we don't 
stale allocations left from the old allocator?

Best regards,

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.