Re: [Valgrind-users] Errors with gcc -static

[John R. <jr...@bi...>]

Nicholas Nethercote wrote:
> On Fri, Jul 17, 2009 at 2:16 AM, Zachary Turner<div...@gm...> wrote:
>> --track-origins=yes I find that the memory it's claiming is
>> uninitialized comes from sbrk().  As far as I can tell (please correct
>> me if I'm wrong) this function is guaranteed to return 0-filled
>> memory

> I'm not at all certain this is the case, which is why Memcheck marks
> it as undefined.  Evidence to the contrary would be welcome!

0)  sbrk() can *decrease* process address space.  No zero fill is done
    for a decrease, not even the fragment on the high end of the last page
    that is beyond the new highest address.  For maximum safety and
    portability, then the bytes in the last page that reside above [the new]
    sbrk(0) should be considered to be uninitialized, but in practice
    it is exceedingly likely that they will retain their previous contents.

1)  If an increase is large enough to require new whole pages,
    then those new whole pages (like all new pages) are zero-filled
    by the operating system.  So if sbrk(0) already is page aligned,
    then sbrk(PAGE_SIZE) *does* zero-fill the new memory.

2)  Any increase that lies within an existing allocated page
    is not changed.  So if (x= sbrk(0)) is not page aligned, then
    sbrk(PAGE_SIZE) yields ((PAGE_SIZE -1) & -x) bytes which
    keep their existing contents, and an additional PAGE_SIZE
    bytes which are zeroed.  ((PAGE_SIZE -1) & x) of them are
    "covered" by the sbrk(), and the rest of them come along for
    the ride because the operating system deals only in whole pages.
    Again, for maximum safety and portability, then anything that
    lives above [the new] sbrk(0) should be considered uninitialized,
    but in practice will retain previous contents [zero in this case.]

Also remember that sbrk(...) can fail  :-)

--