Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables
Date
Msg-id 3989.1536457182@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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


pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15374: Error al ejecutar el paso de post instalacion
Next
From: Tom Lane
Date:
Subject: Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables