Date: Thu, 2 Jul 2015 22:45:11 +0300 From: Constantine <iamvfx@...il.com> To: musl@...ts.openwall.com, Constantine <iamvfx@...il.com> Subject: Re: Commit 01d4274 breaks Clang's LeakSanitizer when used with musl > This happens for all programs, even when there are no dlopen/dlsym errors? > Does the error happen at start, at exit, or some other time while the program is running? At start, only for those programs which are compiled with Clang and -fsanitize=leak flag. > (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) Ah, you're right, they intercept free function there... But how introduced change in that commit may affect it? I see only two `free` calls in __dl_thread_cleanup... > of course all this is completely broken and not fixable on the musl side.. Not completely! :) At least it works if that commit is reversed. On Thu, Jul 2, 2015 at 10:29 PM, Szabolcs Nagy <nsz@...t70.net> wrote: > * 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.. > > -- *コンスタンティン* *・タラセンコフ*https://procedural.github.io 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.