Обсуждение: BUG #19095: Test if function exit() is used fail when linked static

The following bug has been logged on the website:

Bug reference:      19095
Logged by:          Torsten Rupp
Email address:      torsten.rupp@gmx.net
PostgreSQL version: 15.14
Operating system:   Linux
Description:

Note: occur from version 15.14 or newer.

In src/interfaces/libpq/Makefile is a test if the function "exit()" (or in
general: a function exists with the name part "exit") is used:

libpq-refs-stamp: $(shlib)
ifneq ($(enable_coverage), yes)
ifeq (,$(filter aix solaris,$(PORTNAME)))
        @if nm -A -u $< 2>/dev/null | grep -v __cxa_atexit | grep exit; then
\
                echo 'libpq must not be calling any function which invokes
exit'; exit 1; \
        fi
endif
endif

This test fail if libpq is linked static to an application when e. g.
libcrypto is also linked static into libpq which add indirectly a call to
"pthread_exit()".

Possible fix: exclude pthread_exit(), too (like __cxa_atexit), e.g.:

libpq-refs-stamp: $(shlib)
ifneq ($(enable_coverage), yes)
ifeq (,$(filter aix solaris,$(PORTNAME)))
        @if nm -A -u $< 2>/dev/null | grep -v __cxa_atexit | grep -v
pthread_exit | grep exit; then \
                echo 'libpq must not be calling any function which invokes
exit'; exit 1; \
        fi
endif
endif

On Mon, Oct 27, 2025 at 07:56:38AM +0000, PG Bug reporting form wrote:
> This test fail if libpq is linked static to an application when e. g.
> libcrypto is also linked static into libpq which add indirectly a call to
> "pthread_exit()".
>
> Possible fix: exclude pthread_exit(), too (like __cxa_atexit), e.g.:

Previous discussions around this check:
- 936f56988741, with:
https://www.postgresql.org/message-id/CAEhC_BmNGKgj2wKArH2EAU11BsaHYgLnrRFJGRm5Vs8WJzyiQA@mail.gmail.com
- dc227eb82ea8, with:
https://www.postgresql.org/message-id/3128896.1624742969@sss.pgh.pa.us

We have usually used the buildfarm to decide how much restriction we
should put into this one, for good historical reasons because we
should never exit() directly from libpq, like this one:
https://www.postgresql.org/message-id/20210703001639.GB2374652@rfd.leadboat.com

Treating pthread_exit() as an exception sounds like it may be a good
thing anyway: we don't rely on it in the code core.

Now I am not completely sure how much we should care about considering
that any of that as something we need to tweak in the core code.  The
use of static libraries are usually discouraged, because it makes the
handling of package dependencies more complicated if some
sub-libraries need to be upgraded following a CVE-class issue, and
here you are pointing at what looks like a custom static library build
of libcrypto on Linux.

Opinions from others are welcome, mine counts like -0.5.
--
Michael

Dear developers,

I opened this request for a behavior concerning functions with the name
part "exit":

 > Bug reference:      19095
> Logged by:          Torsten Rupp
> Email address:      torsten.rupp@gmx.net
> PostgreSQL version: 15.14
> Operating system:   Linux
> Description:
>
> Note: occur from version 15.14 or newer.
>
> In src/interfaces/libpq/Makefile is a test if the function "exit()" (or in
> general: a function exists with the name part "exit") is used:
>
> libpq-refs-stamp: $(shlib)
> ifneq ($(enable_coverage), yes)
> ifeq (,$(filter aix solaris,$(PORTNAME)))
>          @if nm -A -u $< 2>/dev/null | grep -v __cxa_atexit | grep exit; then
> \
>                  echo 'libpq must not be calling any function which invokes
> exit'; exit 1; \
>          fi
> endif
> endif
>
> This test fail if libpq is linked static to an application when e. g.
> libcrypto is also linked static into libpq which add indirectly a call to
> "pthread_exit()".
>
> Possible fix: exclude pthread_exit(), too (like __cxa_atexit), e.g.:
>
> libpq-refs-stamp: $(shlib)
> ifneq ($(enable_coverage), yes)
> ifeq (,$(filter aix solaris,$(PORTNAME)))
>          @if nm -A -u $< 2>/dev/null | grep -v __cxa_atexit | grep -v
> pthread_exit | grep exit; then \
>                  echo 'libpq must not be calling any function which invokes
> exit'; exit 1; \
>          fi
> endif
> endif

BTW: if you wonder about static linkage: I'm aware of the disadvantages,
but I use static linkage for a backup tool which should run e. g. in any
live Linux from a USB medium, thus it should have as less dependencies
to shared libraries as possible. A non-static version of the tool is
also available. The issue does not occur with shared libraries, because
then no function with the name part "exit" is linked into libpq.

Thank you for your attention.

Best regards, Torsten Rupp

BharatDB <bharatdbpg@gmail.com> writes:
>> [1]Changing the grep pattern to match the exact symbol ('grep -x exit')
>> prevents such false positives.

We might as well remove the test entirely as do that; it would
fail to detect "_exit" for example.

Additionally, I don't have a lot of faith in "grep -x" being
universally portable.  POSIX 2018 does specify that switch, but
it mentions that it is "historically available only with fgrep".

Personally I'm okay with whitelisting pthread_exit() as
Torsten suggested.

BTW, it looks like libpq's meson.build is missing this check.

            regards, tom lane

> On 12 Nov 2025, at 07:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Personally I'm okay with whitelisting pthread_exit() as
> Torsten suggested.

+1, we already have a few whitelisted entries and pthread_exit seems perfectly
reasonable to add to that list.

--
Daniel Gustafsson

On Wed, Nov 12, 2025 at 09:13:09AM +0100, Daniel Gustafsson wrote:
> On 12 Nov 2025, at 07:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Personally I'm okay with whitelisting pthread_exit() as
>> Torsten suggested.
>
> +1, we already have a few whitelisted entries and pthread_exit seems perfectly
> reasonable to add to that list.

WFM.
--
Michael

> On 12 Nov 2025, at 09:15, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Nov 12, 2025 at 09:13:09AM +0100, Daniel Gustafsson wrote:
>> On 12 Nov 2025, at 07:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Personally I'm okay with whitelisting pthread_exit() as
>>> Torsten suggested.
>>
>> +1, we already have a few whitelisted entries and pthread_exit seems perfectly
>> reasonable to add to that list.
>
> WFM.

The attached trivial diff adds this to the whitelist clause in the Makefile.  I
experimented with adding this to Meson, and while it's trivial enough to do the
run_command with libpq_so.full_path, it's less clear to me exactly where in the
build it should be added.  I've pinged my colleague Bilal who is much better at
Meson than me to collaborate on that as a separate fix.

--
Daniel Gustafsson

Hi,
On 2025-11-14 13:11:15 +0100, Daniel Gustafsson wrote:
> > On 12 Nov 2025, at 09:15, Michael Paquier <michael@paquier.xyz> wrote:
> > 
> > On Wed, Nov 12, 2025 at 09:13:09AM +0100, Daniel Gustafsson wrote:
> >> On 12 Nov 2025, at 07:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> Personally I'm okay with whitelisting pthread_exit() as
> >>> Torsten suggested.
> >> 
> >> +1, we already have a few whitelisted entries and pthread_exit seems perfectly
> >> reasonable to add to that list.
> > 
> > WFM.
> 
> The attached trivial diff adds this to the whitelist clause in the Makefile.  I
> experimented with adding this to Meson, and while it's trivial enough to do the
> run_command with libpq_so.full_path, it's less clear to me exactly where in the
> build it should be added.  I've pinged my colleague Bilal who is much better at
> Meson than me to collaborate on that as a separate fix.

For meson we'll have to filter where we test this more strictly - it'll
e.g. not work on windows, because there's no nm, perhaps no grep, etc.

But more generally: If we allow pthread_exit(), what's the point of this test?
That's one of the functions we better avoid calling, no?


ISTM that if we do want to continue having this test, the issue is that we're
testing the shared library - which will have already linked against static
libraries like the sanitizer ones or in this case libcrypto. What we ought to
do is to test the .o files constituting libpq.so, rather than the already
linked .so. That way we will find our own calls to exit etc, but not ones in
static libraries.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> But more generally: If we allow pthread_exit(), what's the point of this test?
> That's one of the functions we better avoid calling, no?

ATM it's not something we'd be tempted to call, but I take your point.

> ISTM that if we do want to continue having this test, the issue is that we're
> testing the shared library - which will have already linked against static
> libraries like the sanitizer ones or in this case libcrypto. What we ought to
> do is to test the .o files constituting libpq.so, rather than the already
> linked .so. That way we will find our own calls to exit etc, but not ones in
> static libraries.

My recollection is that that doesn't help as much as you'd think.
__tsan_func_exit, for one, can get injected into our own .o files
if we build with appropriate sanitizers enabled.

            regards, tom lane

Hi,

On Fri, 14 Nov 2025 at 15:11, Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 12 Nov 2025, at 09:15, Michael Paquier <michael@paquier.xyz> wrote:
> >
> > On Wed, Nov 12, 2025 at 09:13:09AM +0100, Daniel Gustafsson wrote:
> >> On 12 Nov 2025, at 07:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> Personally I'm okay with whitelisting pthread_exit() as
> >>> Torsten suggested.
> >>
> >> +1, we already have a few whitelisted entries and pthread_exit seems perfectly
> >> reasonable to add to that list.
> >
> > WFM.
>
> The attached trivial diff adds this to the whitelist clause in the Makefile.  I
> experimented with adding this to Meson, and while it's trivial enough to do the
> run_command with libpq_so.full_path, it's less clear to me exactly where in the
> build it should be added.  I've pinged my colleague Bilal who is much better at
> Meson than me to collaborate on that as a separate fix.

Sorry for the late reply. I replaced the Makefile portion with the
Perl script, so that it can be used for both meson and autoconf build
systems. The script takes two arguments

- input_file -> path of library file.
- stamp_file -> to create a stamp file for the meson build, so that
meson does not run while the library file is not changed. Autoconf
build does not use this option.

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

Hi,

On Wed, 19 Nov 2025 at 16:17, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
>
> Sorry for the late reply. I replaced the Makefile portion with the
> Perl script, so that it can be used for both meson and autoconf build
> systems.

Apparently we do not need to remove the stamp-file in the perl script,
meson already handles that internally. v2 is attached.

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

On Mon, Nov 24, 2025 at 02:04:01PM +0300, Nazir Bilal Yavuz wrote:
> Apparently we do not need to remove the stamp-file in the perl script,
> meson already handles that internally. v2 is attached.

Good idea to embed that in a perl script!

> +# Check for functions that libpq must not call, currently just exit().
> +# (Ideally we'd reject abort() too, but there are various scenarios where
> +# build toolchains insert abort() calls, e.g. to implement assert().)
> +# If nm doesn't exist or doesn't work on shlibs, this test will do nothing,
> +# which is fine.  The exclusion of __cxa_atexit is necessary on OpenBSD,
> +# which seems to insert references to that even in pure C code. Excluding
> +# __tsan_func_exit is necessary when using ThreadSanitizer data race detector
> +# which use this function for instrumentation of function exit.
> +# Skip the test when profiling, as gcc may insert exit() calls for that.
> +# Also skip the test on platforms where libpq infrastructure may be provided
> +# by statically-linked libraries, as we can't expect them to honor this
> +# coding rule.

Including a reference to "nm" in this comment for meson is definitely
fine, because it is used as a pre-check in this code with
find_program.  However, shouldn't we document the platform-specific
exclusions in the perl script itself?  As of the patch, the
explanation is a copy-paste of src/interfaces/libpq/Makefile.  I think
that we'd better group everything together, rather than have the same
contents explained in two places.  Perhaps I would add an extra
comment in meson.build and the Makefile to document that all the
platform-relevant details are in the perl script itself.

I would be also tempted to move the solaris check inside the perl
script rather than have it duplicated across meson and make, then do
something based on $Config{osname} instead.
--
Michael

Hi,

On Tue, 25 Nov 2025 at 12:11, VASUKI M <vasukim1992002@gmail.com> wrote:
>
> On Tue, 25 Nov 2025 at 03:14, Michael Paquier <michael@paquier.xyz> wrote:
>>
>> Including a reference to "nm" in this comment for meson is definitely
>> fine, because it is used as a pre-check in this code with
>> find_program.  However, shouldn't we document the platform-specific
>> exclusions in the perl script itself?  As of the patch, the
>> explanation is a copy-paste of src/interfaces/libpq/Makefile.  I think
>> that we'd better group everything together, rather than have the same
>> contents explained in two places.  Perhaps I would add an extra
>> comment in meson.build and the Makefile to document that all the
>> platform-relevant details are in the perl script itself.
>>
> Thanks for this suggestion michael & Nazir for the code,i have made the changes you said
>
> Also added the check where it scans for nm in the environment if it is not present then it gracefully skips the
test.
> V3 attached kindly check and review it.

Thank you for working on this!

diff --git a/src/interfaces/libpq/Makefile b/src/interfaces/libpq/Makefile
index da66500..305361f 100644
--- a/src/interfaces/libpq/Makefile
+++ b/src/interfaces/libpq/Makefile

-ifeq (,$(filter solaris,$(PORTNAME)))
-    @if nm -A -u $< 2>/dev/null | grep -v -e __cxa_atexit -e
__tsan_func_exit | grep exit; then \
-        echo 'libpq must not be calling any function which invokes
exit'; exit 1; \
-    fi
+    # See libpq-exit-check for full platform rules and whitelisting.
+    $(PERL) libpq-exit-check --input_file $<
 endif
-endif
-    touch $@
+    touch $@

There are unnecessary indentation changes.

diff --git a/src/interfaces/libpq/libpq-exit-check
b/src/interfaces/libpq/libpq-exit-check
new file mode 100755
index 0000000..f500cef
--- /dev/null
+++ b/src/interfaces/libpq/libpq-exit-check

I would prefer more in-line comments instead of the comment at the top
but I think this is a preference.

diff --git a/src/interfaces/libpq/meson.build b/src/interfaces/libpq/meson.build
index a74e885..1b32eed 100644
--- a/src/interfaces/libpq/meson.build
+++ b/src/interfaces/libpq/meson.build

+if find_program('nm', required: false, native: true).found() and not
get_option('b_coverage')

I would delete the 'nm' check there, since we have the same check in
the PERL script. This makes the meson.build and the Makefile more
similar.

Also, I would change the comment at the Makefile and the meson.build
with the comment below, otherwise we lose information:

# Check for functions that libpq must not call, currently just exit().
# (Ideally we'd reject abort() too, but there are various scenarios where
# build toolchains insert abort() calls, e.g. to implement assert().)
# Skip the test when profiling, as gcc may insert exit() calls for that.

Nitpick: I suggest running pgperltidy [1] on the libq-exit-check PERL file.

[1] https://github.com/postgres/postgres/blob/master/src/tools/pgindent/pgperltidy

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

> On 25 Nov 2025, at 10:11, VASUKI M <vasukim1992002@gmail.com> wrote:

> Thanks for this suggestion michael & Nazir for the code,i have made the changes you said
>
> Also added the check where it scans for nm in the environment if it is not present then it gracefully skips the test.

+if find_program('nm', required: false, native: true).found() and not get_option('b_coverage')
Sorry for being late to the party, but I wonder why we aren't adding this check
to the toplevel meson.build and configure.ac (via config/programs.m4) like how
we check for all others tools used by the build?  Such checks should of course
not fail the configuration, merely record the presence or absence of the tool.
The path can then be exported to src/interfaces/libpq/{Makefile|meson.build} to
use.


+open my $fh, '-|', "$nm_path -A -u $input_file 2>/dev/null"
This filehandle is never closed.


+# ---- Skip entirely on Solaris ----
+if ($Config{osname} =~ /solaris/i) {
+    exit 0;
+}
This won't work on Windows either, which wasn't checked for in the Makefile
since make isn't used on Windows.

--
Daniel Gustafsson

On Tue, Nov 25, 2025 at 11:51:55AM +0100, Daniel Gustafsson wrote:
> +if find_program('nm', required: false, native: true).found() and not get_option('b_coverage')
> Sorry for being late to the party, but I wonder why we aren't adding this check
> to the toplevel meson.build and configure.ac (via config/programs.m4) like how
> we check for all others tools used by the build?  Such checks should of course
> not fail the configuration, merely record the presence or absence of the tool.
> The path can then be exported to src/interfaces/libpq/{Makefile|meson.build} to
> use.

+1 for this find_program() call grouped at the top of meson.build,
grouped with the others.
--
Michael

> On 3 Dec 2025, at 12:59, VASUKI M <vasukim1992002@gmail.com> wrote:

> This is a refreshed version of the patch to unify the exit() reference check
> performed during libpq builds. Earlier versions had duplicated logic between
> the Makefile and Meson builds, while platform-specific details were also split
> between comments and build rules.

Thanks for the update.  This patch builds on previous patches posted in the
thread which makes it more complicated to review.  Can you please post a full
squashed patch against master so we can be absolutely sure we are looking at
the tree in the same state that you are.

--
Daniel Gustafsson

On Thu, Dec 04, 2025 at 12:33:55AM +0100, Daniel Gustafsson wrote:
> Thanks for the update.  This patch builds on previous patches posted in the
> thread which makes it more complicated to review.  Can you please post a full
> squashed patch against master so we can be absolutely sure we are looking at
> the tree in the same state that you are.

Yeah, I was just playing with this patch a little bit this morning,
and reworked it as the attached, adjusting a bunch of stuff inside it.
The main complaint that I have with v4 is the fact that the new check
for pthread_exit() was not split as a patch of its own, being hidden
in the perl script introduced.

Saying that, passing the path of nm as argument to the perl script is
something that feels OK here, as does the coverage check added twice
for meson and Makefile, rather than relying on enable_coverage in an
ENV.  Feel free to comment on these points, of course.

There were a few other things (comments, etc.) that I have tweaked
(commit message not edited, stolen from v4), but feel free to see the
attached for all the details.  libpq fails properly after planting
some exit() calls reported by nm.  I have run once autoreconf while on
it, before running a check in the CI, which was also OK.
--
Michael

On Thu, Dec 04, 2025 at 04:38:40PM +0530, VASUKI M wrote:
> This v6 series is squashed and rebased on the current master. It also
> includes the revisions and clarifications suggested in the previous round
> of review, including Michael’s comments.

Including the changes in ./configure is not mandatory for patch
authors, as this is something that committers take care of.  Still,
these are useful for the CI and testing the ./configure code.

> I agree with the approach of keeping the coverage
> condition local to each build system rather than relying on
> enable_coverage  as
> an environment variable. In practice, autoconf (enable_coverage) and Meson
> (b_coverage) expose their coverage settings independently, so duplicating
> the
> check avoids any accidental cross-build inconsistencies. It also prevents
> the
> script from having to detect build-system-specific flags internally, keeping
> libpq-check.pl focused only on symbol inspection. So I think it makes sense
> for Makefile and Meson to each guard their own invocation. What do you
> think?

The only differences I can see between v5 and v6 is that the perl
script uses whitespaces for its code indentation rather than tabs,
which I guess is not expected.  Most of the diffs between v6 and v5 go
away once a perl indentation is applied.

I am not going to take a bet on this one on a Friday, so let's give it
a few more days.  Have others any comments and/or concerns?
--
Michael

On Mon, Dec 08, 2025 at 10:11:08AM +0530, VASUKI M wrote:
> Regarding the whitespace comment - I had already ran the pgperltidy on the
> perl script libpq-check.pl before  sending the patch,and I also verified the tab
> indentation with cat -T  to ensure the tabs were being used.FS,The current version of
> the scripts in v6 should already follow the standard pgindent/pgperltidy formatting
>
> If there is still any specific section that appears mis-indented on your
> side, please let me know and I will adjust it.

The only documentation that I have been following on this matter
exists in src/tools/pgindent/README.  That may be an issue with your
environment, I cannot say for sure.  And I am pretty sure that my
environment is handling things the way the README tells.

Anyway, after more review of the refactoring patch, I have noticed
that we were losing quite a few details about the reasons why we are
doing things the way they are.

So I have added more details about to keep things a maximum consistent
with what we had documented:
- The shared library check requirement, mentioning that the check is
skipped for static libraries in the Makefile case (for meson, we use
libpq_so, so that did not seem strongly necessary to add there,
perhaps we should).
- The explanation for __cxa_atexit, related to OpenBSD, reusing the
same wording as previously, but in the script.
- The explanation for __tsan_func_exit with ThreadSanitizer, reusing
the same wording as previously, but in the script.

Then applied the result as 4a8e6f43a6b5.  Running the check for meson
may bring some surprises, but we'll see.  The buildfarm looks OK for
the moment.  Once we are completely in the clear, let's move on with
the second patch.
--
Michael

On 09.12.25 05:16, Michael Paquier wrote:
> Then applied the result as 4a8e6f43a6b5.  Running the check for meson
> may bring some surprises, but we'll see.  The buildfarm looks OK for
> the moment.  Once we are completely in the clear, let's move on with
> the second patch.

meson gives this warning now:

../src/meson.build:31: WARNING: The variable(s) 'NM' in the input file 
'src/Makefile.global.in' are not present in the given configuration data.

Looks like a small addition on src/makefiles/meson.build would fix it.

On Tue, Dec 09, 2025 at 07:10:09AM +0100, Peter Eisentraut wrote:
> meson gives this warning now:
>
> ../src/meson.build:31: WARNING: The variable(s) 'NM' in the input file
> 'src/Makefile.global.in' are not present in the given configuration data.
>
> Looks like a small addition on src/makefiles/meson.build would fix it.

Oops.  Let me see..  Indeed, the warning shows during the "Configuring
Makefile.global using configuration" step.  This information has been
showing up in my logs while testing meson.

The attached takes care of the issue here.  Adding that to pgxs_bins
may look adapted at first glance, but I don't quite see the point in
exposing this information to PGXS, so pgxs_empty is a better fit?

What do you think?
--
Michael

Hi,

On Tue, 9 Dec 2025 at 13:23, VASUKI M <vasukim1992002@gmail.com> wrote:
>
> Thanks Michael and Peter for the detailed reviews and for taking the time to refine and commit the updated version.
>
> Thanks for pointing out that pgperltidy may behave differently across environments.
>
> On Tue, 9 Dec 2025 at 11:56, Michael Paquier <michael@paquier.xyz> wrote:
>>
>> The attached takes care of the issue here.  Adding that to pgxs_bins
>> may look adapted at first glance, but I don't quite see the point in
>> exposing this information to PGXS, so pgxs_empty is a better fit?
>>
> Thanks for the clarification.Given that PGXS extensions don't appear to require NM ,IMO adding it to pgxs_empty makes
senseto me.It resolves the Meson warning without exposing unnecessary variables to PGXS users.
 

I agree with both of you. We do the same thing for 'ZIC' binary, so I
think putting it to pgxs_empty is the correct fix.

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

On Tue, Dec 09, 2025 at 03:47:13PM +0300, Bilal Yavuz wrote:
> I agree with both of you. We do the same thing for 'ZIC' binary, so I
> think putting it to pgxs_empty is the correct fix.

Thanks for double-checking.  I was not 100% sure if my analysis was
completely right as I was looking at this file for the first time.
--
Michael

On Wed, Dec 10, 2025 at 08:11:37AM +0900, Michael Paquier wrote:
> On Tue, Dec 09, 2025 at 03:47:13PM +0300, Bilal Yavuz wrote:
>> I agree with both of you. We do the same thing for 'ZIC' binary, so I
>> think putting it to pgxs_empty is the correct fix.
>
> Thanks for double-checking.  I was not 100% sure if my analysis was
> completely right as I was looking at this file for the first time.

On top of the rest, I have double-checked the buildfarm and things
seem fine with 4a8e6f43a6b5, so the last piece about pthread_exit() is
now done with 8268e66ac64c.
--
Michael