[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150702194634.GJ32532@port70.net>
Date: Thu, 2 Jul 2015 21:46:34 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com, Constantine <iamvfx@...il.com>
Subject: Re: Commit 01d4274 breaks Clang's LeakSanitizer when used
with musl
* Szabolcs Nagy <nsz@...t70.net> [2015-07-02 21:29:16 +0200]:
> * 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..
hm wait a minute, interception was not supposed to work with musl
it still uses -Bsymbolic-functions so my analysis cant be correct
i dont know why it worked before and why that check fails now
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.
