Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers

Peter Geoghegan <pg(at)heroku(dot)com> writes:
> 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?

Not sure. There are wide swaths of the system where it would be perfectly
valid to see a pointer into buffer storage, so long as you still had a pin
on that page.

However, after further consideration it seems like even without solving
the buffer-reaccess problem, a Valgrind tweak such as above would have
caught this bug, and probably most other similar bugs. Running with a
large shared_buffers value actually works in our favor for this: you're
unlikely to get aliasing between different pages occupying the same
buffer. And most queries don't (intentionally) re-access the same page,
so while detection of a stale pointer wouldn't be certain it'd be fairly
probable.

regards, tom lane