From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/15096 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: d.dorau@avm.de Newsgroups: gmane.linux.lib.musl.general Subject: Re[2]: Issue with musl and valgrind Date: Mon, 6 Jan 2020 17:24:35 +0100 Message-ID: References: <20200106135623.GO30412@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005A245DC12584E7_=" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="209676"; mail-complaints-to="usenet@blaine.gmane.org" Cc: musl@lists.openwall.com To: "Rich Felker" Original-X-From: musl-return-15112-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 06 17:28:05 2020 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1ioVEa-000sQw-OF for gllmg-musl@m.gmane.org; Mon, 06 Jan 2020 17:28:04 +0100 Original-Received: (qmail 1833 invoked by uid 550); 6 Jan 2020 16:28:02 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1788 invoked from network); 6 Jan 2020 16:28:01 -0000 Resent-From: Rich Felker Resent-Date: Mon, 6 Jan 2020 11:27:48 -0500 Resent-Message-ID: <20200106162748.GP30412@brightrain.aerifal.cx> Resent-To: musl@lists.openwall.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=avm.de; s=mail; t=1578327876; bh=pp7/hP8pFCNp7oHVJ8xjyB0VLBxEMspbsvcp3/cOS0g=; h=In-Reply-To:References:To:Subject:From:Date:From; b=Iwemh2bmrdHv1+g1hr6GZzFtHKRr6siUF/5ts2B7TGBwvqQK7Ks+sxv9KRMA+LRCP V2yGPmGg4V0vyDACAc5scNbs699f2ZZSmHuxLpz1lKKoXN1bjpsOKlJlSB9ccECeQL VdqlKDeHH/927wM3M4IgJYynnEZThRcLvHRq2ZZE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=avm.de; s=mail; t=1578327876; bh=pp7/hP8pFCNp7oHVJ8xjyB0VLBxEMspbsvcp3/cOS0g=; h=In-Reply-To:References:To:Subject:From:Date:From; b=Iwemh2bmrdHv1+g1hr6GZzFtHKRr6siUF/5ts2B7TGBwvqQK7Ks+sxv9KRMA+LRCP V2yGPmGg4V0vyDACAc5scNbs699f2ZZSmHuxLpz1lKKoXN1bjpsOKlJlSB9ccECeQL VdqlKDeHH/927wM3M4IgJYynnEZThRcLvHRq2ZZE= In-Reply-To: <20200106135623.GO30412@brightrain.aerifal.cx> X-KeepSent: 8AD17947:D5D5D702-C12584E7:00597957; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1 October 14, 2013 X-MIMETrack: Serialize by Router on ANIS1/AVM(Release 10.0.1FP3|August 09, 2019) at 06.01.2020 17:24:35, Serialize complete at 06.01.2020 17:24:35 X-purgate-ID: 149429::1578327875-000004DE-A59ADE28/0/0 X-purgate-type: clean X-purgate-size: 6710 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-Filtered-With: renattach 1.2.4 X-RenAttach-Info: mode=badlist action=rename count=0 Resent-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:15096 Archived-At: Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 005A245DC12584E7_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable "Rich Felker" schrieb am 06.01.2020 14:56:23: [...] >=20 > This is really a bug in valgrind, that it's relying on a mix of the > dynamic linker and its own mechanism for interposing malloc. Either > the interposition should not take place until after line 1913 of > =5F=5Fdls3 in dynlink.c (this is what would happen if you did it via > LD=5FPRELOAD without valgrind), or valgrind should do its own loading > and relocation of vgpreload=5Fmemcheck-*.so independent of the tracee's > dynamic linker. >=20 > On most archs, the problem does not manifest as things are setup so > that it's safe to call free in an unrelocated context. However > realloc is gratuitously not safe and Ad=E9lie Linux has a patch for it > to do it like free: >=20 >=20 https://code.foxkit.us/adelie/packages/blob/master/user/valgrind/realloc.pa= tch >=20 > But on MIPS, where there are no PC-relative references and everything > goes through the GOT, this blows up. >=20 > I'm not sure how practical it is to get valgrind to fix this upstream. > In the either/or above, if the first course of action is taken, the > mechanism should probably be by inserting a breakpoint (or valgrind's > equivalent) at the main program's e=5Fentry address and not doing the > replacement hack until then. Alternatively, it could just rely on > LD=5FPRELOAD working without trying to do additional tricks, but maybe > they have a good reason they're not doing that. >=20 > Rich I was not aware of this when debugging the crash, but after looking at=20 additional debug statements and valgrind code my current understanding is that=20 valgrind actually inserts LD=5FPRELOAD=3D" /usr/lib/valgrind/vgpreload=5Fcore-mips32-linux.so:/usr/lib/valgrind/vgprel= oad=5Fmemcheck-mips32-linux.so" into the environment before loading the executable to test. (coregrind/m=5Finitimg/initimg-linux.c:123) 425:11:32:696 --4757:1: main Split up command line 425:11:32:696 --4757:1: main (early=5F) Process Valgrind's command line = options 425:11:32:696 --4757:1: main Create initial image 425:11:32:712 --4757:1: initimg Loading client 425:11:32:712 --4757:1: initimg Setup client env 425:11:32:712 --4757:2: initimg preload=5Fstring: 425:11:32:728 --4757:2: initimg=20 "/usr/lib/valgrind/vgpreload=5Fcore-mips32-linux.so:/usr/lib/valgrind/vgpre= load=5Fmemcheck-mips32-linux.so" 425:11:32:728 --4757:1: initimg Setup client stack: size will be 1048576 Is my understanding correct that you would expect it to not run into the crash I described earlier then? Daniel --=_alternative 005A245DC12584E7_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable "Rich Felker" <dalias@aerifal.cx> schrieb am 06.01.2020 14:56:23:
[...]
>
> This is really a bug in valgrind, that it's relying on a mix of the
> dynamic linker and its own mechanism for interposing malloc. Either
> the interposition should not take place until after line 1913 of
> =5F=5Fdls3 in dynlink.c (this is what would happen if you did it via > LD=5FPRELOAD without valgrind), or valgrind should do its own loading<= br> > and relocation of vgpreload=5Fmemcheck-*.so independent of the tracee'= s
> dynamic linker.
>
> On most archs, the problem does not manifest as things are setup so
> that it's safe to call free in an unrelocated context. However
> realloc is gratuitously not safe and Ad=E9lie Linux has a patch for it
> to do it like free:
>
>
https://code.foxkit.us/ad= elie/packages/blob/master/user/valgrind/realloc.patch
>
> But on MIPS, where there are no PC-relative references and everything<= br> > goes through the GOT, this blows up.
>
> I'm not sure how practical it is to get valgrind to fix this upstream.=
> In the either/or above, if the first course of action is taken, the
> mechanism should probably be by inserting a breakpoint (or valgrind's<= br> > equivalent) at the main program's e=5Fentry address and not doing the<= br> > replacement hack until then. Alternatively, it could just rely on
> LD=5FPRELOAD working without trying to do additional tricks, but maybe=
> they have a good reason they're not doing that.
>
> Rich

I was not aware of this when debugging the crash, but after looking at additional
debug statements and valgrind code my current unders= tanding is that valgrind
actually inserts

LD=5FPRELOAD=3D"/usr/lib/valgrind/vgpreload=5Fcore-mips32-linux.so:/us= r/lib/valgrind/vgpreload=5Fmemcheck-mips32-linux.so"


into the environment before loading the executable to test.
(coregrind/m=5Finitimg/initimg-linux.c:123)

425:11:32:696 --4757:1:    main Split up command line
425:11:32:696 --4757:1:    main (early=5F) Process Valgrind's command line options
425:11:32:696 --4757:1:    main Create ini= tial image
425:11:32:712 --4757:1: initimg Loading client
425:11:32:712 --4757:1: initimg Setup client env
425:11:32:712 --4757:2: initimg   preload=5Fstr= ing:
425:11:32:728 --4757:2: initimg     "= /usr/lib/valgrind/vgpreload=5Fcore-mips32-linux.so:/usr/lib/valgrind/vgprel= oad=5Fmemcheck-mips32-linux.so"
425:11:32:728 --4757:1: initimg Setup client stack: size will be 1048576


Is my understanding correct that you would expect it to not run into
the crash I described earlier then?


Daniel

--=_alternative 005A245DC12584E7_=--