On Thu, Oct 20, 2016 at 06:14:28PM +0100, Greg Stark wrote:
> On Oct 20, 2016 5:27 PM, "Noah Misch" wrote:
> > On Wed, Oct 19, 2016 at 11:08:39AM +0100, Greg Stark wrote:
> > > The MEMPOOL_FREE doesn't take any size argument and mcxt.c doesn't
> > > have convenient access to a size argument. It co
On Oct 20, 2016 5:27 PM, "Noah Misch" wrote:
>
> On Wed, Oct 19, 2016 at 11:08:39AM +0100, Greg Stark wrote:
>
> > 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
On Wed, Oct 19, 2016 at 11:08:39AM +0100, Greg Stark wrote:
> On Sat, Feb 6, 2016 at 4:52 AM, Noah Misch 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()
On Sat, Feb 6, 2016 at 4:52 AM, Noah Misch 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
On Wed, Sep 28, 2016 at 7:40 AM, Piotr Stefaniak
wrote:
> Not remembering the context, I was initially confused about what exactly
> supposedly needs to be done in order to have ASan support, especially
> since I've been using it for a couple of years without any kind of
> modifications. Having re
On 2016-09-28 00:02, Andres Freund wrote:
> On 2015-09-07 17:05:10 +0100, Greg Stark wrote:
>> I feel like I remember hearing about this before but I can't find any
>> mention of it in my mail archives. It seems pretty simple to add
>> support for LLVM's Address Sanitizer (asan) by using the hooks
On 2016-09-27 19:31:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-09-28 00:23:11 +0100, Greg Stark wrote:
> >> 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?
>
> I think
Andres Freund writes:
> On 2016-09-28 00:23:11 +0100, Greg Stark wrote:
>> 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?
I think "((void) 0)" is a more common spelling of a dummy statement.
T
On 2016-09-28 00:23:11 +0100, Greg Stark wrote:
> On Tue, Sep 27, 2016 at 11:02 PM, Andres Freund 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
On Tue, Sep 27, 2016 at 11:02 PM, Andres Freund 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 ther
Hi,
On 2015-09-07 17:05:10 +0100, Greg Stark wrote:
> I feel like I remember hearing about this before but I can't find any
> mention of it in my mail archives. It seems pretty simple to add
> support for LLVM's Address Sanitizer (asan) by using the hooks we
> already have for valgrind.
Any plan
On Mon, Sep 07, 2015 at 05:05:10PM +0100, Greg Stark wrote:
> I feel like I remember hearing about this before but I can't find any
> mention of it in my mail archives. It seems pretty simple to add
> support for LLVM's Address Sanitizer (asan) by using the hooks we
> already have for valgrind.
Ni
12 matches
Mail list logo
