From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Jacob Champion <pchampion@vmware.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Daniel Gustafsson <daniel@yesql.se>
Subject: Re: Preventing abort() and exit() calls in libpq
Date: Mon, 28 Jun 2021 09:47:59 -0400
Message-ID: <151613.1624888079@sss.pgh.pa.us> (raw)
In-Reply-To: <YNl/rGAtp0Ovmtis@paquier.xyz>
References: <3128896.1624742969@sss.pgh.pa.us>
<YNl/rGAtp0Ovmtis@paquier.xyz>
Michael Paquier <michael@paquier.xyz> writes:
> On Sat, Jun 26, 2021 at 05:29:29PM -0400, Tom Lane wrote:
>> I'll stick this into the CF list to see if the cfbot agrees that
>> it finds the abort() problems...
> The CF Bot is finding those problems.
>> +# Check for functions that libpq must not call.
>> +# (If nm doesn't exist or doesn't work on shlibs, this test will silently
>> +# do nothing, which is fine.)
>> +.PHONY: check-libpq-refs
>> +check-libpq-refs: $(shlib)
>> + @! nm -A -g -u $< 2>/dev/null | grep -e abort -e exit
Yeah, all except on Windows. Not sure if it's worth trying to build
some way to make this check on Windows.
> "abort" and "exit" could be generic terms present in some other
> libraries. Could be be better to match with "U abort" and "U exit"
> instead?
No, for a couple of reasons:
* nm's output format isn't all that well standardized
* on some platforms, what appears here is "_abort".
I would have liked to use "-w" in the grep call, but between the
"_abort" case and the "abort@@GLIBC" case we see elsewhere, we'd
be assuming way too much about what grep will consider to be a word.
In practice I don't think it's too much of a problem. It doesn't
matter whether libc has exported names containing "exit", unless
libpq or something it imports from src/common or src/port actually
attempts to call those names. Which I'm not expecting.
A possible counterexample is atexit(3). If libpq ever grew a
reason to call that then we'd have an issue. It wouldn't be
that hard to work around, by adding a grep -v filter. But in
any case I'm dubious that we could ever make correct use of
atexit(3) in libpq, because we'd have no way to know whether
the host application has its own atexit callbacks and if so
whether they'll run before or after libpq's. Something like
isolationtester's atexit callback to PQclose all its connections
would risk breakage if libpq tried to clean up via atexit.
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-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, michael@paquier.xyz, pchampion@vmware.com, daniel@yesql.se
Subject: Re: Preventing abort() and exit() calls in libpq
In-Reply-To: <151613.1624888079@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