<p dir="ltr"><p dir="ltr">On Oct 20, 2016 5:27 PM, "Noah Misch" <<a
href="mailto:noah@leadboat.com">noah@leadboat.com</a>>wrote:<br /> ><br /> > On Wed, Oct 19, 2016 at
11:08:39AM+0100, Greg Stark wrote:<br /> ><br /> > > The MEMPOOL_FREE doesn't take any size argument and
mcxt.cdoesn't<br /> > > have convenient access to a size argument. It could call the<br /> > >
GetChunkSpacemethod but that will include the allocation overhead and<br /> ><br /> > That is indeed a problem
formaking VALGRIND_MEMPOOL_FREE() an alias of<br /> > VALGRIND_MAKE_MEM_NOACCESS() under ASAN as I suggested.
Calling<br/> > GetMemoryChunkSpace() in the macro would cause memdebug.h to embed an<br /> > assumption of
mcxt.c,which is messy. Including the allocation overhead is<br /> > fine, though.<p dir="ltr">I think the way out
isto simply have aset.c make the memory undefined/noaccess even if it's redundant under valgrind. It's a bit
unfortunatethat the macros would have different semantics under the two. If it's too confusing or we're worried about
theperformance overhead we could make a MAKE_MEM_{UNDEFINED,NOACCESS}_IF_NO_MEMPOOL() but I don't think it's worth it
myself.<br/><br /><p dir="ltr">> > in any case isn't this memory already marked noaccess by aset.c?<br /> ><br
/>> Only sometimes, when AllocSetFree() happens to call free() or wipe_mem().<p dir="ltr">I think if I did further
surgeryhere I would rename wipe_mem and randomise_mem and make them responsible for making the memory undefined and
noaccessas well. They would always be defined so that would get rid of all the ifdefs except within those functions.<br
/><pdir="ltr">I have a patch working under asan on both gcc and clang. That handles noaccess but not undefined memory
reads.I need to try msan to make sure the macro definitions work well for that API too.<p dir="ltr">There are a couple
buildoddities both with gcc and clang before I can commit anything though. And I can't test valgrind to be sure the
redundantcalls aren't causing a problem.
