From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Jeremy Evans <code@jeremyevans.net>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
Date: Sat, 08 Sep 2018 21:39:42 -0400
Message-ID: <3989.1536457182@sss.pgh.pa.us> (raw)
In-Reply-To: <31648.1536451185@sss.pgh.pa.us>
References: <153626613985.23143.4743626885618266803@wrigleys.postgresql.org>
<20180906215836.GP2726@paquier.xyz>
<20180906222843.GF17425@jeremyevans.local>
<20180907165103.GH17425@jeremyevans.local>
<20180907175518.GI17425@jeremyevans.local>
<20180907181522.GB32058@paquier.xyz>
<20016.1536351535@sss.pgh.pa.us>
<20180907204403.GC32058@paquier.xyz>
<16558.1536407783@sss.pgh.pa.us>
<18398.1536410055@sss.pgh.pa.us>
<87o9d8rv08.fsf@news-spur.riddles.org.uk>
<3979.1536433320@sss.pgh.pa.us>
<6869.1536436921@sss.pgh.pa.us>
<874lezskcu.fsf@news-spur.riddles.org.uk>
<31648.1536451185@sss.pgh.pa.us>
I wrote:
> Hm. So I can reproduce the crash on NetBSD as well as OpenBSD, using
> the test method I showed before ... but *not* on FreeBSD 11.0 x86_64,
> even though that's certainly an ELF system. So now I'm confused again.
Further debugging shows conclusively that libpq *is* calling the backend
copy of pg_saslprep, and that what it passes to free() came from palloc()
in the case at hand. Apparently, the default malloc library in this
version of FreeBSD is not as good at noticing bad free() arguments as
the other platforms I tested. Probably, the process's malloc freelist
is now corrupt and that would eventually lead to a crash, but I did not
try to prove it.
Adding the proposed patch to the FreeBSD stanza of Makefile.shlib
does cause libpq to start calling the desired version of pg_saslprep.
On the other front of developing a test case to detect this problem,
I did not have much luck with mechanizing this specific test: it
requires some functionality we have in the TAP tests, like setting
up an installation with SCRAM password authentication enabled, as
well as other functionality we have in the isolation tester, like
doing things in two different sessions concurrently. But we don't
really need to test this *exact* scenario; we just need something
that will behave differently if libpq links to backend versions of
any of the problematic functions. I'm a bit tempted to add
something like this to saslprep.c:
bool
saslprep_is_frontend()
{
#ifdef FRONTEND
return true;
#else
return false;
#endif
}
and then have libpq test to make sure this function returns true.
regards, tom lane
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-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew@tao11.riddles.org.uk, code@jeremyevans.net, michael@paquier.xyz, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
In-Reply-To: <3989.1536457182@sss.pgh.pa.us>
* 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