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_UNDEFINED() and VALGRIND_MEMPOOL_FREE() 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 > MEMPOOL_ALLOC/FREE.
Correct. > 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: NOACCESS: - requested_size field of AllocChunkData - Trailing padding, if any, of AllocChunkData - Any chunk bytes after the last byte of the most recent requested size DEFINED: - palloc0() return value, up to requested size UNDEFINED: - 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: http://www.postgresql.org/mailpref/pgsql-hackers
