[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130616191628.GQ29800@brightrain.aerifal.cx>
Date: Sun, 16 Jun 2013 15:16:28 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: valgrind problems
On Sun, Jun 16, 2013 at 07:39:43PM +0200, Jens Gustedt wrote:
> Am Sonntag, den 16.06.2013, 12:04 -0400 schrieb Rich Felker:
> > It's not an indeterminate value. It's simply a value. Because malloc
> > is not special here. It's just like any other function defined in C
> > code on a freestanding implementation.
>
> I agree that malloc is not special here, because it is freestanding,
> no problem. But malloc also gets the memory from some system calls, if
> you don't have a fixed static pool.
>
> These system calls guarantee you that the value of the memory is
> determined. So this is a platform specific guarantee, and valgrind
> doesn't seem to share that information.
>
> 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.
In any case, the behavior of brk and mmap has nothing to do with gcc,
so it's not a matter of gcc-specific assumptions.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
