Re: LLVM Address Sanitizer (ASAN) and valgrind support
От | Greg Stark |
---|---|
Тема | Re: LLVM Address Sanitizer (ASAN) and valgrind support |
Дата | |
Msg-id | CAM-w4HObfQVs=JqcEx3-04g8gXnO4DU6AJNYgczqytSL6PALQA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: LLVM Address Sanitizer (ASAN) and valgrind support (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: LLVM Address Sanitizer (ASAN) and valgrind support
|
Список | pgsql-hackers |
On Sat, Feb 6, 2016 at 4:52 AM, Noah Misch <noah@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. 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
В списке pgsql-hackers по дате отправления: