From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3437 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: valgrind problems Date: Sun, 16 Jun 2013 21:38:25 +0200 Message-ID: <20130616193825.GH6548@port70.net> References: <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> <20130616153117.GO29800@brightrain.aerifal.cx> <1371398332.5692.108.camel@eris.loria.fr> <20130616160435.GP29800@brightrain.aerifal.cx> <1371404383.5692.122.camel@eris.loria.fr> <20130616191628.GQ29800@brightrain.aerifal.cx> 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 1371411521 19820 80.91.229.3 (16 Jun 2013 19:38:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Jun 2013 19:38:41 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3441-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 16 21:38:42 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 1UoImf-0003MA-Mm for gllmg-musl@plane.gmane.org; Sun, 16 Jun 2013 21:38:41 +0200 Original-Received: (qmail 13530 invoked by uid 550); 16 Jun 2013 19:38:41 -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 13522 invoked from network); 16 Jun 2013 19:38:41 -0000 Content-Disposition: inline In-Reply-To: <20130616191628.GQ29800@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3437 Archived-At: * Rich Felker [2013-06-16 15:16:28 -0400]: > On Sun, Jun 16, 2013 at 07:39:43PM +0200, Jens Gustedt wrote: > > In particular, valgrind claimed that calloc was using memory > > unitialized that was received with brk. It is platform specific to > > assume that memory returned by brk is initialized to some value, be it > > 0 or not. If this is a linux specific guarantee, valgrind seems to be > > missing it. > > I'm pretty sure valgrind's failure here is not missing the fact that > brk (or any new anonymous pages) are zero pages; it's seeing the call > to a function named "malloc" and treating the memory pointed to by the > result as containing indeterminate values. If valgrind's logic were > merely considering anonymous memory from brk or mmap as indeterminate, > it could not catch errors due to use of indeterminate values in memory > obtained by malloc that was recycled from an earlier call to free. the problem only shows up with static linking where valgrind does not see the malloc call, only brk valgrind thinks that brk is uninitialized it is easy to demonstrate even with glibc (using static linking and valgind --track-origins=yes) so we should just let valgrind know that brk is ok