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

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(at)gmail(dot)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(at)anarazel(dot)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]
>