From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3425 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: valgrind problems Date: Sun, 16 Jun 2013 11:31:17 -0400 Message-ID: <20130616153117.GO29800@brightrain.aerifal.cx> References: <1371333657.16425.350.camel@eris.loria.fr> <20130615221627.GB6548@port70.net> <20130616054006.GJ29800@brightrain.aerifal.cx> <1371367371.16425.363.camel@eris.loria.fr> <1371375118.16425.368.camel@eris.loria.fr> <1371379388.16425.372.camel@eris.loria.fr> <20130616143140.GL29800@brightrain.aerifal.cx> <1371396379.5692.96.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1371396690 15223 80.91.229.3 (16 Jun 2013 15:31:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Jun 2013 15:31:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3429-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 16 17:31:32 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UoEvT-0005GS-JS for gllmg-musl@plane.gmane.org; Sun, 16 Jun 2013 17:31:31 +0200 Original-Received: (qmail 21729 invoked by uid 550); 16 Jun 2013 15:31:31 -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 21715 invoked from network); 16 Jun 2013 15:31:30 -0000 Content-Disposition: inline In-Reply-To: <1371396379.5692.96.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3425 Archived-At: On Sun, Jun 16, 2013 at 05:26:19PM +0200, Jens Gustedt wrote: > Hello, > > Am Sonntag, den 16.06.2013, 10:31 -0400 schrieb Rich Felker: > > Is there no way to make the suppression more fine-grained? For > > example, "ignore up to wordsize-1 sequential invalid reads in this > > function" would give the desired behavior. glibc has some sort of > > suppression for these functions; what does valgrind do for glibc? > > I think it basically wraps its own code around some functions. Or > maybe just replaces them? > > Such an approach obviously doesn't work if we link the C library > statically. I just wanted to try to link statically against glibc to > see what happens, but got stuck with other stuff. I see. Have you tried dynamic linking with musl? > > > Also for calloc I am not sure that when we switch off the false > > > positive (where musl assumes a certain gcc behavior for what in > > > general is UB) > > > > musl is not assuming any gcc behavior. > > unfortunately it does. as an optimization shortcut it reads the newly > allocated bytes and if they are already 0, it doesn't write to > them. This is not gcc behavior. It's behavior of it's own implementation of malloc. From the implementation's standpoint, the object returned by malloc does not have indeterminate value; otherwise it would be impossible to link it with its bookkeeping information, contained in the header of the object, and to later free it. In other words, if you required the implementation to treat malloc as a black box, it would be impossible to implement free. > So this uses the fact that the newly allocated memory has an > unspecified, but determined value to do some optimization. > > It is exactly that line of calloc.c, namely the `if` in line 20 that > triggers under valgrind. > > In a recent discussion with the C committee I have learned that there > is no consensus of whether an unspecified value is determined and > wouldn't change once it is observed or whether it could be "wobbling" > (the term that someone used, there). There are even people that > propose to have a sort of state outside the object representation that > captures if memory has been initialized or not. This applies to applications but not to the implementation itself. That's why musl is compiled with -ffreestanding: to tell the compiler that functions with standard names are not black boxes it can assume behave according to how they would on a hosted implementation, but that we're implementing them. Rich