Обсуждение: 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