Date: Thu, 2 Jul 2015 23:10:52 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Cc: Constantine <iamvfx@...il.com> Subject: Re: Commit 01d4274 breaks Clang's LeakSanitizer when used with musl * Constantine <iamvfx@...il.com> [2015-07-02 22:45:11 +0300]: > > 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... > the lsan alloc symbols are statically linked into the application so they override the extern calls in shared objects eg in libstdc++.so if you linked a c++ application and if the lsan initialization somehow called into libstdc++.so (it is not supposed to, but lsan is c++ code so you can never know) and free is called there then you'd get the observed behaviour. (this scenario has a few ifs and does not explain why the specific commit broke it, but i dont see other way now) it would be easier to know what happens if you put a breakpoint on __sanitizer::CheckFailed and printed a backtrace (or replace that code with __builtin_trap and rebuid compiler_rt that way to get a proper core dump)
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.