mailing list of musl libc
 help / color / mirror / code / Atom feed
* calloc question about clearing allocated memory
@ 2017-06-26 21:30 Vicente Bergas
  2017-06-27 13:13 ` Szabolcs Nagy
  0 siblings, 1 reply; 3+ messages in thread
From: Vicente Bergas @ 2017-06-26 21:30 UTC (permalink / raw)
  To: musl

Hello,
when compiling a program against the musl libc and running it under
valgrind, then it reports lots of uninitialized value errors.
I have tracked them down to only two sources:
http://git.musl-libc.org/cgit/musl/tree/src/string/strlen.c?id=e6def544#n15
http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c?id=e6def544#n375

The first one about strlen is clearly an optimization everybody would
like to have, but the second one in __malloc0 is not that obvious.
Please, could that be explained: why is *z read just before being
cleared?
In fact it is counter-intuitive and looks like an overhead.
In case there is a reason for it, it would be nice to put an
explanatory comment there. Otherwise, that extra read could be
removed to make valgrind happy.

Regards,
  Vicenç.

P.S.: Please, CC me as I am not subscribed to the list.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: calloc question about clearing allocated memory
  2017-06-26 21:30 calloc question about clearing allocated memory Vicente Bergas
@ 2017-06-27 13:13 ` Szabolcs Nagy
  2017-06-27 18:24   ` Vicente Bergas
  0 siblings, 1 reply; 3+ messages in thread
From: Szabolcs Nagy @ 2017-06-27 13:13 UTC (permalink / raw)
  To: Vicente Bergas; +Cc: musl

* Vicente Bergas <vicencb@gmail.com> [2017-06-26 23:30:53 +0200]:
> Hello,
> when compiling a program against the musl libc and running it under
> valgrind, then it reports lots of uninitialized value errors.
> I have tracked them down to only two sources:
> http://git.musl-libc.org/cgit/musl/tree/src/string/strlen.c?id=e6def544#n15
> http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c?id=e6def544#n375
> 
> The first one about strlen is clearly an optimization everybody would
> like to have, but the second one in __malloc0 is not that obvious.
> Please, could that be explained: why is *z read just before being
> cleared?
> In fact it is counter-intuitive and looks like an overhead.
> In case there is a reason for it, it would be nice to put an
> explanatory comment there. Otherwise, that extra read could be
> removed to make valgrind happy.

this should be the faq of the month..

a zero page does not take up resources, however when
it is written (even if that's just 0) the page gets
dirty and it does take up resources (and the write
operation would cause a page fault introducing
significant delays)

so if(*z) *z=0; should be an obvious optimization.
that said the current code is not optimal and an
improvement was just posted:
http://www.openwall.com/lists/musl/2017/06/26/1
but that won't fix the valgrind issue: to fix that
valgrind just needs to be taught not to report
uninitialized error for calloced memory.

> 
> Regards,
>   Vicenç.
> 
> P.S.: Please, CC me as I am not subscribed to the list.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: calloc question about clearing allocated memory
  2017-06-27 13:13 ` Szabolcs Nagy
@ 2017-06-27 18:24   ` Vicente Bergas
  0 siblings, 0 replies; 3+ messages in thread
From: Vicente Bergas @ 2017-06-27 18:24 UTC (permalink / raw)
  To: musl

Thanks for the explanation, now it is clear!

On Tue, Jun 27, 2017 at 3:13 PM, Szabolcs Nagy <nsz@port70.net> wrote:
> * Vicente Bergas <vicencb@gmail.com> [2017-06-26 23:30:53 +0200]:
>> Hello,
>> when compiling a program against the musl libc and running it under
>> valgrind, then it reports lots of uninitialized value errors.
>> I have tracked them down to only two sources:
>> http://git.musl-libc.org/cgit/musl/tree/src/string/strlen.c?id=e6def544#n15
>> http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c?id=e6def544#n375
>>
>> The first one about strlen is clearly an optimization everybody would
>> like to have, but the second one in __malloc0 is not that obvious.
>> Please, could that be explained: why is *z read just before being
>> cleared?
>> In fact it is counter-intuitive and looks like an overhead.
>> In case there is a reason for it, it would be nice to put an
>> explanatory comment there. Otherwise, that extra read could be
>> removed to make valgrind happy.
>
> this should be the faq of the month..
>
> a zero page does not take up resources, however when
> it is written (even if that's just 0) the page gets
> dirty and it does take up resources (and the write
> operation would cause a page fault introducing
> significant delays)
>
> so if(*z) *z=0; should be an obvious optimization.
> that said the current code is not optimal and an
> improvement was just posted:
> http://www.openwall.com/lists/musl/2017/06/26/1
> but that won't fix the valgrind issue: to fix that
> valgrind just needs to be taught not to report
> uninitialized error for calloced memory.
>
>>
>> Regards,
>>   Vicenç.
>>
>> P.S.: Please, CC me as I am not subscribed to the list.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-06-27 18:24 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-26 21:30 calloc question about clearing allocated memory Vicente Bergas
2017-06-27 13:13 ` Szabolcs Nagy
2017-06-27 18:24   ` Vicente Bergas

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).