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