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] >