Date: Thu, 2 Jul 2015 21:46:34 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com, Constantine <iamvfx@...il.com> Subject: Re: Commit 01d4274 breaks Clang's LeakSanitizer when used with musl * Szabolcs Nagy <nsz@...t70.net> [2015-07-02 21:29:16 +0200]: > * Rich Felker <dalias@...c.org> [2015-07-02 15:00:37 -0400]: > > On Thu, Jul 02, 2015 at 09:22:28PM +0300, Constantine wrote: > > > See this commit in cgit: > > > > > > http://git.musl-libc.org/cgit/musl/commit/?id=01d4274 > > > > > > "make dlerror state and message thread-local and dynamically-allocated" > > > > > > > > > With this commit any application compiled with lsan yelds this error which > > > stops the application from running: > > > > > > ==15531==Sanitizer CHECK failed: > > > > /mnt/space/llvm/projects/compiler-rt/lib/lsan/lsan_interceptors.cc:58 > > > > ((!lsan_init_is_running)) != (0) (0, 0) > > > > > > > > > But if I revert 01d4274 > > > <https://github.com/procedural/musl-patches/blob/d9fab50/revert_01d4274.patch> > > > on musl 1.1.9 or higher versions, the error goes away and lsan works as > > > expected. > > > > > > Just letting you guys know that this commit breaks external tools like lsan. > > > > This happens for all programs, even when there are no dlopen/dlsym > > errors? That seems really odd, since the changed code should be > > unreachable in the absence of such errors. Does the error happen at > > start, at exit, or some other time while the program is running? > > > > Whatever the cause is, I'm pretty sure it's on the lsan side, and not > > musl's fault. But it would be nice to get some more information so we > > can check and maybe send a useful report to lsan for fixing whatever > > is broken. > > > > i think the cause is that they intercept all allocation functions > and if the act of interception calls into the intercepted function > itself then they have a problem > > this happens on glibc with calloc and i think on musl with free > (at least that line is the interceptor for free and they do enough > shady things in their free wrapper to cause a libc internal free call) > > of course all this is completely broken and not fixable on the musl side.. > > for glibc calloc they have some ugly workaround, maybe similar hack > is needed for free in musl, but none of this is future proof so > they will just keep piling hacks.. hm wait a minute, interception was not supposed to work with musl it still uses -Bsymbolic-functions so my analysis cant be correct i dont know why it worked before and why that check fails now
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.