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
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 |