mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: valgrind problems
Date: Sun, 16 Jun 2013 21:38:25 +0200	[thread overview]
Message-ID: <20130616193825.GH6548@port70.net> (raw)
In-Reply-To: <20130616191628.GQ29800@brightrain.aerifal.cx>

* Rich Felker <dalias@aerifal.cx> [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


  reply	other threads:[~2013-06-16 19:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-15 22:01 [PATCH] bugfix: initialize a state variable in lio_wait Jens Gustedt
2013-06-15 22:16 ` Szabolcs Nagy
2013-06-16  5:40   ` Rich Felker
2013-06-16  7:22     ` Jens Gustedt
2013-06-16  9:31       ` Jens Gustedt
2013-06-16 10:18         ` Justin Cormack
2013-06-16 10:43           ` valgrind problems Jens Gustedt
2013-06-16 11:39             ` Szabolcs Nagy
2013-06-16 14:16               ` Jens Gustedt
2013-06-16 14:36                 ` Rich Felker
2013-06-16 14:31             ` Rich Felker
2013-06-16 15:26               ` Jens Gustedt
2013-06-16 15:31                 ` Rich Felker
2013-06-16 15:58                   ` Jens Gustedt
2013-06-16 16:04                     ` Rich Felker
2013-06-16 17:39                       ` Jens Gustedt
2013-06-16 19:16                         ` Rich Felker
2013-06-16 19:38                           ` Szabolcs Nagy [this message]
2013-06-16 19:41                             ` Rich Felker
2013-06-16 17:40                     ` Szabolcs Nagy
2013-06-16 18:02                       ` Jens Gustedt
2013-06-16 19:25                         ` Szabolcs Nagy
2013-06-16 19:29                           ` Rich Felker
2013-06-16 14:24         ` [PATCH] bugfix: initialize a state variable in lio_wait Rich Felker
2013-06-16 15:48           ` Jens Gustedt
2013-06-16 15:37   ` Szabolcs Nagy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130616193825.GH6548@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).