From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: valgrind issues on Fedora 28
Date: Fri, 14 Dec 2018 13:49:11 +0100
Message-ID: <4721dbaf-b922-9e30-e635-00f06512edac@2ndquadrant.com> (raw)
In-Reply-To: <16353.1544760625@sss.pgh.pa.us>
References: <20181106173527.omm63tiaguxft7mg@alvherre.pgsql>
<f6577fe9-def2-7614-958f-9a8fb810f666@2ndquadrant.com>
<23c8e539-6777-1793-0939-12e73cb98314@2ndquadrant.com>
<9063c043-83cd-b439-a928-622a743edd2c@2ndquadrant.com>
<16353.1544760625@sss.pgh.pa.us>
On 12/14/18 5:10 AM, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> On 11/8/18 1:07 PM, Tomas Vondra wrote:
>>> Not sure what to do about this - maybe we should wildcard this first
>>> frame, to accept all wcsnlen variants. Opinions?
>
>> I've committed this with the first frame wirldcarded, and backpatched it
>> all the way back to 9.4.
>
> So I just got around to trying to do some valgrind testing for the first
> time in a couple of months, and what I find is that this patch completely
> breaks valgrind for me: it exits immediately with complaints like
>
> ==00:00:00:00.222 14821== FATAL: in suppressions file "/home/postgres/pgsql/src/tools/valgrind.supp" near line 227:
> ==00:00:00:00.222 14821== unknown tool suppression type
> ==00:00:00:00.222 14821== exiting now.
>
> After a bit of hair-pulling I found that the line number report is
> a lie, and what it's really unhappy about is the "Memcheck:Addr32"
> specification on line 236. This is not terribly surprising perhaps
> considering that "Addr32" isn't even documented on what should be
> the authoritative page:
> http://valgrind.org/docs/manual/mc-manual.html#mc-manual.suppfiles
>
Hmm :-( FWIW the Addr32 comes directly from valgrind itself, which
explicitly suggested to add suppression like this:
{
<insert_a_suppression_name_here>
Memcheck:Addr32
fun:__wcsnlen_avx2
fun:wcsrtombs
fun:wcstombs
fun:wchar2char
fun:str_tolower
fun:lower
fun:DirectFunctionCall1Coll
fun:Generic_Text_IC_like
...
}
My guess is that documentation is either somewhat obsolete, or is meant
more like a general description than an exhaustive and authoritative
source of truth regarding suppressions.
> This is valgrind 3.8.1 (RHEL6's version), so not bleeding edge exactly,
> but we have very little evidence about how far back the committed patch
> works. I'm inclined to think we can't use this solution.
>
Fedora 28 has 3.14.0, so this seems to be due to some improvements since
3.8.1. I'm not sure how to deal with this - surely we don't want to just
revert the change because that would start generating noise again. For a
moment I thought we might wildcard the error type somehow, so that it
would accept Memcheck:* but AFAICs that is not supported.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, tgl@sss.pgh.pa.us, alvherre@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
Subject: Re: valgrind issues on Fedora 28
In-Reply-To: <4721dbaf-b922-9e30-e635-00f06512edac@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox