Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.