Non-reproducible valgrind failure on HEAD
I happened to be trying to run the core regression tests under
valgrind, and I got the complaints attached below, from the
process that had been running the insert_conflict test script.
I could not reproduce the failure in a second run, which is not
hugely surprising because it appears to be in cross-process
sinval processing; so timing sensitivity is to be expected.
That doesn't make it any less disturbing.
One point worth mentioning is that I'd forgotten to build with
"#define USE_VALGRIND" in the first try. AFAIK that should make
valgrind strictly less sensitive, so I think it's not material,
but still.
Thoughts?
regards, tom lane
Attachments:
386293.logtext/plain; charset=us-ascii; name=386293.logDownload
Hi,
On 2021-05-09 15:29:06 -0400, Tom Lane wrote:
I happened to be trying to run the core regression tests under
valgrind, and I got the complaints attached below, from the
process that had been running the insert_conflict test script.I could not reproduce the failure in a second run, which is not
hugely surprising because it appears to be in cross-process
sinval processing; so timing sensitivity is to be expected.
That doesn't make it any less disturbing.One point worth mentioning is that I'd forgotten to build with
"#define USE_VALGRIND" in the first try. AFAIK that should make
valgrind strictly less sensitive, so I think it's not material,
but still.
I think it may be material - see the comments in
AddCatcacheInvalidationMessage(). Valgrind doesn't cope correctly with
the sinval ringbuffer being accessed in multiple processes. If process A
adds an invalidation to position 0 and then later processes another
invalidation at the same position 0 that was added by B, valgrind will
use the "is defined" state from the invalidation it queued itself, not
the one that B queued.
Greetings,
Andres Freund
Andres Freund <andres@anarazel.de> writes:
On 2021-05-09 15:29:06 -0400, Tom Lane wrote:
One point worth mentioning is that I'd forgotten to build with
"#define USE_VALGRIND" in the first try. AFAIK that should make
valgrind strictly less sensitive, so I think it's not material,
but still.
I think it may be material - see the comments in
AddCatcacheInvalidationMessage().
Ah-hah. Please excuse the noise.
(I wonder if we shouldn't adjust the comments in pg_config_manual.h,
though, as they certainly leave the impression that USE_VALGRIND
isn't essential.)
regards, tom lane
Hi,
On 2021-05-09 17:12:14 -0400, Tom Lane wrote:
(I wonder if we shouldn't adjust the comments in pg_config_manual.h,
though, as they certainly leave the impression that USE_VALGRIND
isn't essential.)
That'd make sense to me. If we found a better way to deal with the
sinval thing it'd be good too - but I am not seeing anything convincing,
and I looked a couple times over the years...
Andres Freund <andres@anarazel.de> writes:
On 2021-05-09 17:12:14 -0400, Tom Lane wrote:
(I wonder if we shouldn't adjust the comments in pg_config_manual.h,
though, as they certainly leave the impression that USE_VALGRIND
isn't essential.)
That'd make sense to me. If we found a better way to deal with the
sinval thing it'd be good too - but I am not seeing anything convincing,
and I looked a couple times over the years...
Yeah, it's actually somewhat amazing that we get useful results at all
around shared-memory accesses.
Proposed comment patch attached.
regards, tom lane