> 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@port70.net> wrote:

> * Rich Felker <dalias@libc.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