MIME-Version: 1.0
References: <19095-6d8256d0c37d4be2@postgresql.org>
In-Reply-To: <19095-6d8256d0c37d4be2@postgresql.org>
From: BharatDB <bharatdbpg@gmail.com>
Date: Wed, 12 Nov 2025 11:23:10 +0530
Message-ID: <CAAh00ETwx8_AEM0wgoi-v875uC-FLuGGOMTaP9fCNdVw4Zq=Vg@mail.gmail.com>
Subject: Re: BUG #19095: Test if function exit() is used fail when linked static
To: torsten.rupp@gmx.net, pgsql-bugs@lists.postgresql.org, michael@paquier.xyz
Cc: VASUKI M <vasukim1992002@gmail.com>
Content-Type: multipart/mixed; boundary="000000000000fbc8ae06435f5f6a"
Archived-At: <https://www.postgresql.org/message-id/CAAh00ETwx8_AEM0wgoi-v875uC-FLuGGOMTaP9fCNdVw4Zq%3DVg%40mail.gmail.com>
Precedence: bulk

--000000000000fbc8ae06435f5f6a
Content-Type: multipart/alternative; boundary="000000000000fbc8ac06435f5f68"

--000000000000fbc8ac06435f5f68
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
>
> Hello Hackers,
>
> While reproducing a static linking issue between libpq and libcrypto.a,
> I observed that the Makefile's symbol check incorrectly reports missing
> exit() symbols because 'grep exit' also matches 'atexit' and
> 'OPENSSL_atexit', etc.
>
> As discussed in the thread by Michael Paquier
> (https://www.postgresql.org/message-id/aQA1obboZFjqjaBI%40paquier.xyz),
> it seems a related fix was committed earlier. However, I was able to
> reproduce this issue again using PostgreSQL 18 (latest release).
>
> Steps to reproduce:
>   nm -A -u ./src/interfaces/libpq/libpq.a
> /usr/lib/x86_64-linux-gnu/libcrypto.a 2>/dev/null | grep -v __cxa_atexit =
|
> grep exit
>
> Output:
>   /usr/lib/x86_64-linux-gnu/libcrypto.a:libcrypto-lib-init.o:
>     U atexit
>   /usr/lib/x86_64-linux-gnu/libcrypto.a:libdefault-lib-rand_unix.o:
>     U OPENSSL_atexit
>
> This falsely triggers an undefined exit() error.
> [1]Changing the grep pattern to match the exact symbol ('grep -x exit')
> prevents
> such false positives.

[2]Alternatively, excluding pthread_exit() (similar to
> __cxa_atexit) would also avoid the issue.
>
>   But [1] will handle all the false positives instead of just pthread_exi=
t
.LGTM

Expected (after fix):
>   no output =E2=80=94 no false positives.
>
> Patch attached.I would love to hear any suggestions from the committers.
>
  Thanks in advance

>
> Best regards,
> Vasuki M
>
    BharatDB,

> CDAC Chennai.
>

--000000000000fbc8ac06435f5f68
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><br>Hello Hackers,<br><br>While re=
producing a static linking issue between libpq and libcrypto.a,<br>I observ=
ed that the Makefile&#39;s symbol check incorrectly reports missing<br>exit=
() symbols because &#39;grep exit&#39; also matches &#39;atexit&#39; and<br=
>&#39;OPENSSL_atexit&#39;, etc.<br><br>As discussed in the thread by Michae=
l Paquier<br>(<a href=3D"https://www.postgresql.org/message-id/aQA1obboZFjq=
jaBI%40paquier.xyz">https://www.postgresql.org/message-id/aQA1obboZFjqjaBI%=
40paquier.xyz</a>),<br>it seems a related fix was committed earlier. Howeve=
r, I was able to<br>reproduce this issue again using PostgreSQL 18 (latest =
release).<br><br>Steps to reproduce:<br>=C2=A0 nm -A -u ./src/interfaces/li=
bpq/libpq.a /usr/lib/x86_64-linux-gnu/libcrypto.a 2&gt;/dev/null | grep -v =
__cxa_atexit | grep exit<br><br>Output:<br>=C2=A0 /usr/lib/x86_64-linux-gnu=
/libcrypto.a:libcrypto-lib-init.o: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 U atexit<br>=C2=A0 /usr/lib/x86_64-linux-gnu/libcrypto.a:=
libdefault-lib-rand_unix.o: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 U OPENSSL_at=
exit<br><br>This falsely triggers an undefined exit() error. =C2=A0<br>[1]C=
hanging the grep pattern to match the exact symbol (&#39;grep -x exit&#39;)=
 prevents<br>such false positives.</blockquote><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">[2]Alternatively, excluding pthread_exit() (similar t=
o<br>__cxa_atexit) would also avoid the issue.<br><br></blockquote><div>=C2=
=A0 But [1] will handle all the false positives instead of just pthread_exi=
t .LGTM<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Expe=
cted (after fix):<br>=C2=A0 no output =E2=80=94 no false positives.<br><br>=
Patch attached.I would love to hear any suggestions from the committers.<br=
></blockquote><div>=C2=A0 Thanks in advance=C2=A0=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><br>Best regards, =C2=A0<br>Vasuki M =
=C2=A0<br></blockquote><div>=C2=A0 =C2=A0 BharatDB,=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">CDAC Chennai.<br>
</blockquote></div></div>

--000000000000fbc8ac06435f5f68--
--000000000000fbc8ae06435f5f6a
Content-Type: text/x-patch; charset="US-ASCII"; 
	name="0001-Fix-prevent-false-exit-match-in-libpq-static-link-ch.patch"
Content-Disposition: attachment; 
	filename="0001-Fix-prevent-false-exit-match-in-libpq-static-link-ch.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mhvl37mg0>
X-Attachment-Id: f_mhvl37mg0

RnJvbSA2YmE3ODRlMjdmNmQyYTcwMjM4MjgyNjNmOTg4YjdhMjcxNmZlNjE0IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBCaGFyYXREQlBHIDxiaGFyYXRkYnBnQGdtYWlsLmNvbT4KRGF0
ZTogVHVlLCAxMSBOb3YgMjAyNSAxNzozNjoyOSArMDUzMApTdWJqZWN0OiBbUEFUQ0hdIEZpeDog
cHJldmVudCBmYWxzZSBleGl0KCkgbWF0Y2ggaW4gbGlicHEgc3RhdGljIGxpbmsgY2hlY2sKClRo
ZSBwcmV2aW91cyBNYWtlZmlsZSBjaGVjayB1c2VkICdncmVwIGV4aXQnLCB3aGljaCBhbHNvIG1h
dGNoZWQKc3ltYm9scyBsaWtlICdhdGV4aXQnIGFuZCAnT1BFTlNTTF9hdGV4aXQnIGZyb20gbGli
Y3J5cHRvLmEuClRoaXMgY2F1c2VkIGZhbHNlIHBvc2l0aXZlIGxpbmsgZmFpbHVyZXMgd2hlbiBz
dGF0aWNhbGx5IGxpbmtpbmcKbGlicHEgd2l0aCBPcGVuU1NMLgoKVXNlICdncmVwIC14IGV4aXQn
IHRvIG1hdGNoIG9ubHkgdGhlIGV4YWN0IHN5bWJvbCBuYW1lLgoKU2lnbmVkLW9mZi1ieTogQmhh
cmF0REJQRyA8YmhhcmF0ZGJwZ0BnbWFpbC5jb20+Ci0tLQogc3JjL2ludGVyZmFjZXMvbGlicHEv
TWFrZWZpbGUgfCAyICstCiAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDEgZGVsZXRp
b24oLSkKCmRpZmYgLS1naXQgYS9zcmMvaW50ZXJmYWNlcy9saWJwcS9NYWtlZmlsZSBiL3NyYy9p
bnRlcmZhY2VzL2xpYnBxL01ha2VmaWxlCmluZGV4IGRhNjY1MDAuLjhjZmYzMGIgMTAwNjQ0Ci0t
LSBhL3NyYy9pbnRlcmZhY2VzL2xpYnBxL01ha2VmaWxlCisrKyBiL3NyYy9pbnRlcmZhY2VzL2xp
YnBxL01ha2VmaWxlCkBAIC0xNDQsNyArMTQ0LDcgQEAgJChzdGxpYik6ICQoT0JKU19TVEFUSUMp
CiBsaWJwcS1yZWZzLXN0YW1wOiAkKHNobGliKQogaWZuZXEgKCQoZW5hYmxlX2NvdmVyYWdlKSwg
eWVzKQogaWZlcSAoLCQoZmlsdGVyIHNvbGFyaXMsJChQT1JUTkFNRSkpKQotCUBpZiBubSAtQSAt
dSAkPCAyPi9kZXYvbnVsbCB8IGdyZXAgLXYgLWUgX19jeGFfYXRleGl0IC1lIF9fdHNhbl9mdW5j
X2V4aXQgfCBncmVwIGV4aXQ7IHRoZW4gXAorCUBpZiBubSAtQSAtdSAkPCAyPi9kZXYvbnVsbCB8
IGdyZXAgLXYgLWUgX19jeGFfYXRleGl0IC1lIF9fdHNhbl9mdW5jX2V4aXQgfCBncmVwIC14IGV4
aXQ7IHRoZW4gXAogCQllY2hvICdsaWJwcSBtdXN0IG5vdCBiZSBjYWxsaW5nIGFueSBmdW5jdGlv
biB3aGljaCBpbnZva2VzIGV4aXQnOyBleGl0IDE7IFwKIAlmaQogZW5kaWYKLS0gCjIuNDMuMAoK
--000000000000fbc8ae06435f5f6a--