On Wed, Oct 19, 2016 at 11:08:39AM +0100, Greg Stark wrote:
> On Sat, Feb 6, 2016 at 4:52 AM, Noah Misch <n...@leadboat.com> wrote:
> > aset.c relies on the fact that VALGRIND_MEMPOOL_ALLOC() has an implicit
> > VALGRIND_MAKE_MEM_NOACCESS().  #define those two accordingly.  If ASAN has 
> > no
> Actually this is confusing.
> aset.c doesn't actually use the MEMPOOL_ALLOC macro at all, it just
> calls UNDEFINED, DEFINED, and NOACCESS. mcxt.c does however do the


> So both layers are calling these macros for
> overlapping memory areas which I find very confusing and I'm not sure
> what the net effect is.

The net effect looks like this, at the instant an mcxt.c function returns:

- requested_size field of AllocChunkData
- Trailing padding, if any, of AllocChunkData
- Any chunk bytes after the last byte of the most recent requested size

- palloc0() return value, up to requested size

- palloc() return value, up to requested size
- repalloc() new portion, after size increase (with MEMORY_CONTEXT_CHECKING
  disabled, memory unfortunately becomes DEFINED instead)

> The MEMPOOL_FREE doesn't take any size argument and mcxt.c doesn't
> have convenient access to a size argument. It could call the
> GetChunkSpace method but that will include the allocation overhead and

That is indeed a problem for making VALGRIND_MEMPOOL_FREE() an alias of
VALGRIND_MAKE_MEM_NOACCESS() under ASAN as I suggested.  Calling
GetMemoryChunkSpace() in the macro would cause memdebug.h to embed an
assumption of mcxt.c, which is messy.  Including the allocation overhead is
fine, though.

> in any case isn't this memory already marked noaccess by aset.c?

Only sometimes, when AllocSetFree() happens to call free() or wipe_mem().

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to