Re: BUG #19095: Test if function exit() is used fail when linked static

BharatDB <bharatdbpg@gmail.com>

From: BharatDB <bharatdbpg@gmail.com>
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: torsten.rupp@gmx.net, pgsql-bugs@lists.postgresql.org, VASUKI M <vasukim1992002@gmail.com>, daniel@yesql.se, michael@paquier.xyz
Date: 2025-11-19T12:29:09Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

Sorry,for the wrong patch this is the correct one.kindly find the attached
patch for testing
I would love to hear the feedback from you committers.

regards,
Vasuki M
BharatDB,C-DAC Chennai.

On Wed, Nov 19, 2025 at 2:38 PM BharatDB <bharatdbpg@gmail.com> wrote:

> Hi Andres and hackers,
> I came up with the solution
> — short follow-up with what I changed and how the Meson check actually
> runs.
>
> Summary of what I did
>   - Added a Meson custom_target in src/interfaces/libpq/meson.build that
>     scans libpq's object files for direct exit() references.
>   - Added pthread_exit to the Makefile whitelist (the Makefile test
>     already existed; this just updates the whitelist).
>   -Added the custom target in the top level meson.build
>
> Where the Meson check lives and when it runs
>   - I put the custom_target in src/interfaces/libpq/meson.build,
>     immediately after the libpq shared/static library targets are
>     defined and after the declare_dependency for libpq.  That is the
>     correct location in the libpq build file.
>   - The custom_target declares `depends: [libpq_st, libpq_so]`.  This
>     is important: it tells Meson to build those targets first so the
>     .o files are present in the build directory before the check runs.
>     The check itself does not scan libpq_st or libpq_so; it scans
>     files in build/src/interfaces/libpq/*.o.
>   - The command uses `find <builddir>/src/interfaces/libpq -name '*.o'`
>     and runs `nm -u` on each .o, piping through `grep -v` for the
>     whitelisted names and finally checking for exit.
>   - The check is skipped for:
>       * cross-builds
>       * when coverage (b_coverage) is enabled
>       * on Windows (no nm/grep in the same form there) as Andrew questioned
>
> Why pthread_exit is whitelisted
>   - pthread_exit can legitimately appear in a few build/runtime
>     configurations (thread runtimes or link-time glue), and the
>     Makefile test was updated to whitelist it.  The Meson check has the
>     same whitelist so both build systems behave the same.
>   - Whitelisting pthread_exit doesn't remove the value of the test:
>     it only avoids false positives for legitimate thread shutdown code.
>     We still catch direct exit()/ _exit()/abort()-style calls as tom said.
>
> How to reproduce locally
>   - From repo root:
>       rm -rf build
>       meson setup build
>       cd build
>       ninja
>     The custom_target runs as part of the normal build and will fail
>     the build if any .o contains an un-whitelisted exit() reference.
>
> On Fri, Nov 14, 2025 at 7:31 PM Andres Freund <andres@anarazel.de> wrote:
>
> 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?
>>
>  I agree it's worth questioning which functions we allow.  The
>  current choice (whitelist pthread_exit) mirrors the Makefile
>  behavior, avoids false positives, and keeps the test focused on
>  direct process-termination calls authored in our code.  If the
>  community prefers a stricter policy so we can adjust the whitelist.
>
>
>> 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.
>>
>
> TBH After so many test runs I have finalized
> Why scan .o files (not the final .so)?
>   - A shared library is usually linked with other static libraries
>     (libcrypto, sanitizer runtimes).  If we scan the final .so we'll
>     see references that originate in those static libraries and produce
>     false positives.
>   - If we scan the .o files that make up libpq, we only inspect our
>     own compilation units and will catch only exit() calls introduced
>     by our code.
>
> HTH! I attached the patch and also added the meson test output before
> /after of any file containing an 'exit' explicitly; it fails the
> build[ninja].
>
> Regards,
> Vasuki M
> BharatDB[CDAC chennai]
>