Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
Date
Msg-id CAM3SWZSwDQ+8Jz5ecgxBOyvQoDuAGrEfirpLifcTj6vTofKPUw@mail.gmail.com
Whole thread Raw
In response to Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
List pgsql-hackers
On Sat, Jan 24, 2015 at 1:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Another idea is to teach Valgrind that whenever a backend reduces its
> pin count on a shared buffer to zero, that buffer should become undefined
> memory.

That should be fairly straightforward to implement.

> But I don't know if that will help --- if the buffer is then
> re-accessed, is Valgrind able to distinguish freshly-computed pointers
> into it from stale ones?

I don't think so. However, I think that
VALGRIND_CHECK_VALUE_IS_DEFINED() might be used. I believe you could
have Valgrind builds deference a pointer, and make sure that it
pointed into defined memory. But what would the generally useful choke
points for such a check be?

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
Next
From: Tom Lane
Date:
Subject: Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers