Re: LLVM Address Sanitizer (ASAN) and valgrind support

From: Andres Freund <andres(at)anarazel(dot)de>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: LLVM Address Sanitizer (ASAN) and valgrind support
Date: 2016-09-27 23:27:59
Message-ID: 20160927232759.cqxywhc7yujeuweb@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-09-28 00:23:11 +0100, Greg Stark wrote:
> On Tue, Sep 27, 2016 at 11:02 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Any plans to pick this up again?
>
> Yeah, I was just thinking I should pick this up again.
>
> > I vote for renaming the VALGRIND names etc. to something more tool-neutral. I think it's going to be too confusing otherwise.
>
> Hm, the danger there is once I start refactoring things I could get
> bogged down...

Meh, adding a neutral name seems pretty harmless.

> I would love to remove all the #ifdef's and have the
> macros just be no-ops if they're compiled out for example...

Don't we pretty much have that?

#ifdef USE_VALGRIND
#include <valgrind/memcheck.h>
#else
#define VALGRIND_CHECK_MEM_IS_DEFINED(addr, size) do {} while (0)
#define VALGRIND_CREATE_MEMPOOL(context, redzones, zeroed) do {} while (0)
#define VALGRIND_DESTROY_MEMPOOL(context) do {} while (0)
#define VALGRIND_MAKE_MEM_DEFINED(addr, size) do {} while (0)
#define VALGRIND_MAKE_MEM_NOACCESS(addr, size) do {} while (0)
#define VALGRIND_MAKE_MEM_UNDEFINED(addr, size) do {} while (0)
#define VALGRIND_MEMPOOL_ALLOC(context, addr, size) do {} while (0)
#define VALGRIND_MEMPOOL_FREE(context, addr) do {} while (0)
#define VALGRIND_MEMPOOL_CHANGE(context, optr, nptr, size) do {} while (0)
#endif

?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-09-27 23:30:19 Re: hash_create(nelem = 0) does invalid memory accesses
Previous Message Andres Freund 2016-09-27 23:24:49 hash_create(nelem = 0) does invalid memory accesses