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  (Noah Misch <noah@leadboat.com>)
Список 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 по дате отправления:

Предыдущее
От: Pavan Deolasee
Дата:
Сообщение: Re: FSM corruption leading to errors
Следующее
От: Christoph Berg
Дата:
Сообщение: Re: Renaming of pg_xlog and pg_clog