pg.ddx.io pgsql-hackers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
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 16:34:35 -0400
Message-ID: <340320.1624912475@sss.pgh.pa.us> (raw)
In-Reply-To: <3128896.1624742969@sss.pgh.pa.us>
References: <3128896.1624742969@sss.pgh.pa.us>
I wrote:
> This relies on "nm" being able to work on shlibs, which it's not
> required to by POSIX. However, it seems to behave as desired even
> on my oldest dinosaurs. In any case, if "nm" doesn't work then
> we'll just not detect such problems on that platform, which should
> be OK as long as the test does work on common platforms.
> Other than that point I think it's relying only on POSIX-spec
> features.
Further dinosaur-wrangling reveals a small problem on prairiedog
(ancient macOS):
$ nm -A -g -u libpq.5.14.dylib | grep abort
libpq.5.14.dylib:fe-connect.o: _abort
libpq.5.14.dylib:_eprintf.o: _abort
The fe-connect.o reference is from PGTHREAD_ERROR of course,
but what's that other thing? Investigation finds this:
https://opensource.apple.com/source/clang/clang-800.0.38/src/projects/compiler-rt/lib/builtins/eprin...
IOW it seems that this file is pulled in to implement <assert.h>,
and the abort call underlies uses of Assert. So that seems fine
from a coding-rule perspective: it's okay for development builds
to contain core-dumping assertions. It complicates matters for
the proposed patch though.
As far as old macOS goes, it seems like we can work around this
pretty easily, since this version of nm helpfully breaks down
the references by .o file: just add a "grep -v" pass to reject
"_eprintf.o:". However, if there are any other platforms that
similarly convert assert() calls into some direct reference
to abort(), it may be harder to work around it elsewhere.
I guess the only way to know is to see what the buildfarm
says.
Worst case, we might only be able to enforce the prohibition
against exit(). That'd be annoying but it's still much better
than nothing.
regards, tom lane
view thread (57+ messages) latest in thread
Message-ID: <340320.1624912475@sss.pgh.pa.us> Permalink: ../340320.1624912475@sss.pgh.pa.us/ Also on: postgresql.org/message-id/340320.1624912475@sss.pgh.pa.us ·
reply
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: <340320.1624912475@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