mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: valgrind problems
Date: Sun, 16 Jun 2013 11:31:17 -0400	[thread overview]
Message-ID: <20130616153117.GO29800@brightrain.aerifal.cx> (raw)
In-Reply-To: <1371396379.5692.96.camel@eris.loria.fr>

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


  reply	other threads:[~2013-06-16 15:31 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 [this message]
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
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=20130616153117.GO29800@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --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).