From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: LLVM Address Sanitizer (ASAN) and valgrind support |
Date: | 2016-10-19 10:08:39 |
Message-ID: | CAM-w4HObfQVs=JqcEx3-04g8gXnO4DU6AJNYgczqytSL6PALQA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Feb 6, 2016 at 4:52 AM, Noah Misch <noah(at)leadboat(dot)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. 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 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
in any case isn't this memory already marked noaccess by aset.c?
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2016-10-19 11:05:28 | Re: Renaming of pg_xlog and pg_clog |
Previous Message | Pavan Deolasee | 2016-10-19 10:07:56 | Re: FSM corruption leading to errors |