Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130616193825.GH6548@port70.net>
Date: Sun, 16 Jun 2013 21:38:25 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: valgrind problems

* Rich Felker <dalias@...ifal.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

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.