Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
От | Peter Geoghegan |
---|---|
Тема | Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers |
Дата | |
Msg-id | CAM3SWZSwDQ+8Jz5ecgxBOyvQoDuAGrEfirpLifcTj6vTofKPUw@mail.gmail.com обсуждение исходный текст |
Ответ на | Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers
Re: Shortcoming in CLOBBER_FREED_MEMORY coverage: disk buffer pointers |
Список | 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 по дате отправления: