[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 Jun 2017 20:34:51 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: Query regarding malloc if statement
On Mon, Jun 19, 2017 at 03:16:16PM +0000, Jamie Mccrae wrote:
> Hi,
>
> I'm using musl to compile a cross-distro application which I've been having problems with and whilst discussing the problem the developer of another project, was shown a musl malloc function which manually checks the contents of each byte and changes it to 0 if the byte is non-0. This code is in src/malloc/malloc.c as so:
>
> void *__malloc0(size_t n)
> {
> void *p = malloc(n);
> if (p && !IS_MMAPPED(MEM_TO_CHUNK(p))) {
> size_t *z;
> n = (n + sizeof *z - 1)/sizeof *z;
> for (z=p; n; n--, z++) if (*z) *z=0;
> }
> return p;
> }
>
>
> This code causes thousands of errors when using valgrind (in excess of 800,000 for my application) due to checking the value of each byte before it has been set and I have to agree with this other developer that I'm at a loss as to why this is performed. If you step through the array and just set each byte to 0 then there will be no read-before-initialisation error and the function will run much faster due to not having to retrieve the data. Why not instead use:
>
> for (z=p; n; n--, z++) *z=0;
Ah, yet another valgrind false positive. If the memory was allocated
with mmap() (which is different from IS_MMAPPED(), because the latter
means that ONLY the chunk is in that map), then the first write access
will cause a page fault. Avoiding write access therefore improves
performance. A lot. Such a mapping will be read as zero without
consequence.
My advice: Get valgrind to ignore the system library, as it doesn't know
what it's doing there. We already had a lot of reclaim_gaps() fun there.
Ciao,
Markus
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.
