Hi,
On 2019-01-15 03:41:34 +0100, Tomas Vondra wrote:
> On 1/15/19 3:11 AM, Andres Freund wrote:
> > On 2019-01-15 03:07:10 +0100, Tomas Vondra wrote:
> >> I've started observing funny valgrind failures on Fedora 28, possibly
> >> after upgrading from 3.14.0-1 to 3.14.0-7 a couple of days ago. This
> >> time it does not seem like platform-specific issues, though - the
> >> failures all look like this:
> >
> > Any chance you're compiling without USE_VALGRIND defined? IIRC these are
> > precisely what the VALGRIND_MAKE_MEM_DEFINED calls in inval.c are
> > intended to fight:
> > /*
> > * Define padding bytes in SharedInvalidationMessage structs to be
> > * defined. Otherwise the sinvaladt.c ringbuffer, which is accessed by
> > * multiple processes, will cause spurious valgrind warnings about
> > * undefined memory being used. That's because valgrind remembers the
> > * undefined bytes from the last local process's store, not realizing that
> > * another process has written since, filling the previously uninitialized
> > * bytes
> > */
> > VALGRIND_MAKE_MEM_DEFINED(&msg, sizeof(msg));
> >
> >
>
> ... the bang you might have just heard was me facepalming
Heh ;)
> Anyway, I find it interesting that valgrind notices this particular
> place and not the other places, and that it only starts happening after
> a couple of minutes of running the regression tests (~5 minutes or so).
IIRC you basically need to fill the space for sinvals for this to
matter, and individual backends need to be old enough to have previously
used the same space. So it's not that easy to trigger. I don't think
we needed many other such tricks to make valgrind work / other things
like this have been solved via valgrind.supp, so it's not that
surprising that you didn't find anything else...
Greetings,
Andres Freund