On Mon, Jul 20, 2009 at 2:13 PM, John Reiser wrote:
>> Is this info specific to Linux/glibc? AFAICT sbrk/brk
>> isn't even POSIX, which makes it even harder to determine what it
>> should do.
>
> sbrk and brk are not POSIX. However, any system that is a derivative
> of *nix has sbrk and brk becau
> Is this info specific to Linux/glibc? AFAICT sbrk/brk
> isn't even POSIX, which makes it even harder to determine what it
> should do.
sbrk and brk are not POSIX. However, any system that is a derivative
of *nix has sbrk and brk because there are too many softwares (such
as the Bourne shell) w
On Sat, Jul 18, 2009 at 12:55 AM, John Reiser wrote:
> Nicholas Nethercote wrote:
>
> 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 a
Nicholas Nethercote wrote:
> On Fri, Jul 17, 2009 at 2:16 AM, Zachary Turner
> 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
>> memor
On Thu, Jul 16, 2009 at 7:47 PM, Nicholas
Nethercote wrote:
> On Fri, Jul 17, 2009 at 2:16 AM, Zachary Turner
> 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 guara
On Fri, Jul 17, 2009 at 2:16 AM, Zachary Turner 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 th
On 16/07/09 19:23, Tim Post wrote:
> Then there's the corner case, when you are provided only with static
> libs to link with. In that case, do what you can. However, that remains
> a corner case :)
There is no problem linking with static libraries in general, so long as
you don't make the progr
On Thu, 2009-07-16 at 11:16 -0500, Zachary Turner wrote:
> Assuming this assessment is accurate, is it best to deal with this by
> adding appropriate suppressions to the default suppressions file, or
> by modifying valgrind to be smarter and know that sbrk memory is
> always 0-filled?
Its best to
On 16/07/09 17:16, Zachary Turner wrote:
> When I build any program (including an empty main function) using gcc
> -static I get enormous amounts of errors in valgrind. After some
> investigation and asking around I think that at least a large portion
> of them are incorrect. In particular, I ge
When I build any program (including an empty main function) using gcc
-static I get enormous amounts of errors in valgrind. After some
investigation and asking around I think that at least a large portion
of them are incorrect. In particular, I get many errors about
uninitialized memory and condi
10 matches
Mail list logo
