Re: strange valgrind failures (again)

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: strange valgrind failures (again)
Date: 2019-01-15 02:41:34
Message-ID: 8b7acd94-0135-e83e-6b1f-3aa9f608e324@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/15/19 3:11 AM, Andres Freund wrote:
> Hi,
>
> 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

Yes, I've been compiling without USE_VALGRIND, because I've been
rebuilding using a command from shell history and the command-line grew
a bit too long to notice that.

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

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-01-15 02:42:18 Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0
Previous Message Michael Paquier 2019-01-15 02:41:00 Re: Prepare Transaction support for ON COMMIT DROP temporary tables