Re: BUG #15367: Crash in pg_fe_scram_free when using foreign tables

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