Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
Date: 2015-01-24 21:48:43
Message-ID: CAM3SWZSwDQ+8Jz5ecgxBOyvQoDuAGrEfirpLifcTj6vTofKPUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 24, 2015 at 1:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-01-24 22:29:55 Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
Previous Message Tom Lane 2015-01-24 21:31:14 Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers