From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8095 Path: news.gmane.org!not-for-mail From: Constantine Newsgroups: gmane.linux.lib.musl.general Subject: Re: Commit 01d4274 breaks Clang's LeakSanitizer when used with musl Date: Thu, 2 Jul 2015 22:45:11 +0300 Message-ID: References: <20150702190037.GJ1173@brightrain.aerifal.cx> <20150702192916.GI32532@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b672924743a6b0519e9adca X-Trace: ger.gmane.org 1435866476 22289 80.91.229.3 (2 Jul 2015 19:47:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jul 2015 19:47:56 +0000 (UTC) To: musl@lists.openwall.com, Constantine Original-X-From: musl-return-8108-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 02 21:47:47 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZAkSX-0000Rn-Mw for gllmg-musl@m.gmane.org; Thu, 02 Jul 2015 21:47:45 +0200 Original-Received: (qmail 30083 invoked by uid 550); 2 Jul 2015 19:47:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28297 invoked from network); 2 Jul 2015 19:45:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=2fPblHoRhrqEv69/HxVT72xRHA6OmJVEva4KE54YENk=; b=vuKQSTRvz76x6BuCzfYZpuzVRiHczee8pavLoyC5avfB5pljlWDq2H8waV5TLfxQPU Dcm8gr7OIEM66YMohuih4Yr5IH7PKH2k0hI8hdlsfEoOIuT/3F6o+gojj9iLhYxx7Hdm uuxfkw3h0uy1WqCYhd20r71jE4xnhS4N902+OwfN2m9pYA7XSvxrnzBLjip6G3US/yex VSZgGL5xPdWNv8X5h4ZJzf8/zgjIA83LlTXir4Py6ZdgS+5S94KT3EtyZ44OiTBRIkqr l5dLERt04b/W9AVsrgYgwdO9eAJL8/vk1QE7UxmJnLSN7dYsQevvl514M3DZdIiDZRHl JQAQ== X-Received: by 10.182.76.100 with SMTP id j4mr30916670obw.14.1435866311701; Thu, 02 Jul 2015 12:45:11 -0700 (PDT) In-Reply-To: <20150702192916.GI32532@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:8095 Archived-At: --047d7b672924743a6b0519e9adca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > 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=3Dleak 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 wrote: > * Rich Felker [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=3D01d4274 > > > > > > "make dlerror state and message thread-local and dynamically-allocate= d" > > > > > > > > > With this commit any application compiled with lsan yelds this error > which > > > stops the application from running: > > > > > > =3D=3D15531=3D=3DSanitizer CHECK failed: > > > > /mnt/space/llvm/projects/compiler-rt/lib/lsan/lsan_interceptors.cc:= 58 > > > > ((!lsan_init_is_running)) !=3D (0) (0, 0) > > > > > > > > > But if I revert 01d4274 > > > < > https://github.com/procedural/musl-patches/blob/d9fab50/revert_01d4274.pa= tch > > > > > 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 lik= e > 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.. > > --=20 *=E3=82=B3=E3=83=B3=E3=82=B9=E3=82=BF=E3=83=B3=E3=83=86=E3=82=A3=E3=83=B3* *=E3=83=BB=E3=82=BF=E3=83=A9=E3=82=BB=E3=83=B3=E3=82=B3=E3=83=95*https://pr= ocedural.github.io --047d7b672924743a6b0519e9adca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0Thi= s 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 an= d -fsanitize=3Dleak flag.

>=C2=A0<= span style=3D"font-size:12.8000001907349px">(at least that line is the inte= rceptor for free and they do enough
shady things in their free wrapper to cause a libc intern= al free call)

<= /span>
Ah, you'r= e right, they=C2=A0inte= rcept free function there... But how introduced=C2=A0change in that commit = may affect it? I see only two `free` calls in=C2=A0__dl_thread_cleanup...

>=C2=A0of 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:2= 9 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, Const= antine wrote:
> > See this commit in cgit:
> >
> > http://git.musl-libc.org/cgit/musl/= commit/?id=3D01d4274
> >
> > "make dlerror state and message thread-local and dynamically= -allocated"
> >
> >
> > With this commit any application compiled with lsan yelds this er= ror which
> > stops the application from running:
> >
> > =3D=3D15531=3D=3DSanitizer CHECK failed:
> > > /mnt/space/llvm/projects/compiler-rt/lib/lsan/lsan_intercept= ors.cc:58
> > > ((!lsan_init_is_running)) !=3D (0) (0, 0)
> >
> >
> > But if I revert 01d4274
> > <https://gi= thub.com/procedural/musl-patches/blob/d9fab50/revert_01d4274.patch><= br> > > on musl 1.1.9 or higher versions, the error goes away and lsan wo= rks 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 functio= ns
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..<= br>
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..




--
=E3=82=B3=E3=83= =B3=E3=82=B9=E3=82=BF=E3=83=B3=E3=83=86=E3=82=A3=E3=83=B3= = =E3=83=BB=E3=82=BF=E3=83=A9=E3=82=BB=E3=83=B3=E3=82=B3=E3=83=95
https://procedural.github.io
--047d7b672924743a6b0519e9adca--