[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150702211052.GK32532@port70.net>
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.
