MIME-Version: 1.0
From: Sasmit Utkarsh <utkarshsasmit@gmail.com>
Date: Thu, 24 Oct 2024 21:42:19 +0530
Message-ID: <CAM-5MT0B3RUXdWmzeK4DYF_igUKqViYS22pQoMr7pANrLHDVKg@mail.gmail.com>
Subject: Assistance Required: Timeout or Buffer Overflow Issue in PostgreSQL
 Client Application
To: pgsql-general <pgsql-general@postgresql.org>, pgsql-general@lists.postgresql.org
Content-Type: multipart/mixed; boundary="000000000000f82bda06253b4423"
Archived-At: <https://www.postgresql.org/message-id/CAM-5MT0B3RUXdWmzeK4DYF_igUKqViYS22pQoMr7pANrLHDVKg%40mail.gmail.com>
Precedence: bulk

--000000000000f82bda06253b4423
Content-Type: multipart/alternative; boundary="000000000000f82bd906253b4421"

--000000000000f82bd906253b4421
Content-Type: text/plain; charset="UTF-8"

Dear PostgreSQL Community Team,

I hope this message finds you well. I am reaching out for assistance with
an issue encountered in our application, which communicates with PostgreSQL
using the libpq client library.

*Issue Details:*
We have observed a problem where one of the application's threads gets
stuck during a database operation. Below is a stack trace of the affected
thread:

*Application Logs:*
Oct 23 10:08:44.806235 cucmtpccu1 shc-server@2.service[966034]:
0966070{ef5f81a7-d35b-4604-953d-a35665e505b7.010000}KIP8-SQL_get_tpf_rw()-SQL
read data from File Address before lock fa(-1810606079) fa(94145801) fa2
htonl(22549652)
Oct 23 10:08:44.806235 cucmtpccu1 shc-server@2.service[966034]:
0966070{ef5f81a7-d35b-4604-953d-a35665e505b7.010000}KIP8-SQL_get_tpf_rw()
SelectDataCommand = CALL SQL_select_data_procedure($1, $2, NULL, NULL)
hold(0) fa(-1810606079)
Oct 23 10:08:44.807814 cucmtpccu1 shc-server@2.service[966034]: *** buffer
overflow detected ***: terminated

*Stack Trace of Thread 966070:*
#0  0x00000000f7ee1129 __kernel_vsyscall (linux-gate.so.1)
#1  0x00000000f6ba23b7 __poll (libc.so.6)
#2  0x00000000f792e5b5 __interceptor_poll (libasan.so.8)
#3  0x00000000f72b30a8 pqSocketCheck (libpq.so.5)
#4  0x00000000f72b3864 pqWaitTimed (libpq.so.5)
#5  0x00000000f72b38d2 pqWait (libpq.so.5)
#6  0x00000000f72aff03 PQgetResult (libpq.so.5)
#7  0x00000000f72b036a PQexecFinish (libpq.so.5)
#8  0x0000000008106dd4 checkLOCK (server)
#9  0x000000000811d871 SQL_get_tpf_rw (server)
...

The stack trace shows that the thread is stuck in a poll operation while
waiting for socket activity within the PostgreSQL client library (libpq).
We suspect this could be related to a network timeout or issue. However,
the application logs indicate a buffer overflow before the crash, which
raises questions about whether these are related.

*Questions:*
-Could the buffer overflow be causing the crash, and if so, how is it
related to the socket activity?
-Are there specific configurations or checks we should perform to diagnose
this issue further?
-Any suggestions for possible solutions to resolve this problem?

For additional context, I've verified that the specified record does exist
in the database, and I am also attaching the implementation details for the
*checkLOCK* function corresponding to the stack trace.

Please let me know if you need any more details

Your assistance with troubleshooting this would be highly appreciated.

Regards,
Sasmit Utkarsh
+91-7674022625

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

<div dir=3D"ltr"><div>Dear PostgreSQL Community Team,<br><br>I hope this me=
ssage finds you well. I am reaching out for assistance with an issue encoun=
tered in our application, which communicates with PostgreSQL using the libp=
q client library.<br><br><b>Issue Details:</b><br>We have observed a proble=
m where one of the application&#39;s threads gets stuck during a database o=
peration. Below is a stack trace of the affected thread:<br><br><b>Applicat=
ion Logs:</b><br>Oct 23 10:08:44.806235 cucmtpccu1 shc-server@2.service[966=
034]: 0966070{ef5f81a7-d35b-4604-953d-a35665e505b7.010000}KIP8-SQL_get_tpf_=
rw()-SQL read data from File Address before lock fa(-1810606079) fa(9414580=
1) fa2 htonl(22549652)<br>Oct 23 10:08:44.806235 cucmtpccu1 shc-server@2.se=
rvice[966034]: 0966070{ef5f81a7-d35b-4604-953d-a35665e505b7.010000}KIP8-SQL=
_get_tpf_rw() SelectDataCommand =3D CALL SQL_select_data_procedure($1, $2, =
NULL, NULL) hold(0) fa(-1810606079)<br>Oct 23 10:08:44.807814 cucmtpccu1 sh=
c-server@2.service[966034]: *** buffer overflow detected ***: terminated<br=
><br><b>Stack Trace of Thread 966070:</b><br><span style=3D"background-colo=
r:rgb(255,255,0)">#0 =C2=A00x00000000f7ee1129 __kernel_vsyscall (linux-gate=
.so.1)<br>#1 =C2=A00x00000000f6ba23b7 __poll (libc.so.6)<br>#2 =C2=A00x0000=
0000f792e5b5 __interceptor_poll (libasan.so.8)<br>#3 =C2=A00x00000000f72b30=
a8 pqSocketCheck (libpq.so.5)<br>#4 =C2=A00x00000000f72b3864 pqWaitTimed (l=
ibpq.so.5)<br>#5 =C2=A00x00000000f72b38d2 pqWait (libpq.so.5)<br>#6 =C2=A00=
x00000000f72aff03 PQgetResult (libpq.so.5)<br>#7 =C2=A00x00000000f72b036a P=
QexecFinish (libpq.so.5)<br>#8 =C2=A00x0000000008106dd4 checkLOCK (server)<=
/span><br>#9 =C2=A00x000000000811d871 SQL_get_tpf_rw (server)<br>...<br><br=
>The stack trace shows that the thread is stuck in a poll operation while w=
aiting for socket activity within the PostgreSQL client library (libpq). We=
 suspect this could be related to a network timeout or issue. However, the =
application logs indicate a buffer overflow before the crash, which raises =
questions about whether these are related.<br><br><b>Questions:</b><br>-Cou=
ld the buffer overflow be causing the crash, and if so, how is it related t=
o the socket activity?<br>-Are there specific configurations or checks we s=
hould perform to diagnose this issue further?<br>-Any suggestions for possi=
ble solutions to resolve this problem?<br><br></div><div>For additional con=
text, I&#39;ve verified that the specified record does exist in the databas=
e, and I am also attaching the implementation details for the <b>checkLOCK<=
/b> function corresponding to the stack trace.<br><br>Please let me know if=
 you need any more details=C2=A0</div><div><br>Your assistance with trouble=
shooting this would be highly appreciated.</div><div><div><br clear=3D"all"=
><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_si=
gnature"><div dir=3D"ltr"><div>Regards,<br></div><div>Sasmit Utkarsh</div><=
div>+91-7674022625</div></div></div></div></div></div></div>

--000000000000f82bd906253b4421--
--000000000000f82bda06253b4423
Content-Type: text/plain; charset="US-ASCII"; name="checkLOCK.txt"
Content-Disposition: attachment; filename="checkLOCK.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_m2nhxcuz0>
X-Attachment-Id: f_m2nhxcuz0

dm9pZCBjaGVja0xPQ0soaW50MzJfdCBmYSkNCnsNCmludCAgICAgICAgIG5GaWVsZHM7DQppbnQg
ICAgICAgICBuVHVwbGVzOw0KaW50ICAgICAgICAgaSwgajsNClBHcmVzdWx0ICpjaGVja0xPQ0tf
cmVzPU5VTEw7DQpjaGFyIENvbW1hbmRbMTAwXTsNCg0KCUxPR19UUkFDRSgiJXMoKSBmYSglaSko
JTA4WCkiLF9fZnVuY19fLGZhLGZhKTsNCiAgICAgICAgDQoJc25wcmludGYoQ29tbWFuZCxzaXpl
b2YoQ29tbWFuZCksIlNFTEVDVCBwaWQsIGNsYXNzaWQsIG9iamlkIEZST00gcGdfbG9ja3MgV0hF
UkUgb2JqaWQ9JWkiLGZhKTsNCiAgICAgICAgLy9QUWNsZWFyKGNoZWNrTE9DS19yZXMpOw0KCWNo
ZWNrTE9DS19yZXMgPSBQUWV4ZWMoY29ubixDb21tYW5kKTsNCg0KICAgICAgICBpZiAoIWNoZWNr
TE9DS19yZXMpIHsNCiAgICAgICAgICAgTE9HX0RFQlVHKCJJbiAlcygpOiBQR3Jlc3VsdCBpcyBz
dGlsbCBOVUxMIHNvIHJldHVybiIsIF9fZnVuY19fKTsNCiAgICAgICAgICAgcmV0dXJuOw0KICAg
ICAgICB9DQoNCiAgICAgICAgaWYgKFBRcmVzdWx0U3RhdHVzKGNoZWNrTE9DS19yZXMpICE9IFBH
UkVTX1RVUExFU19PSykgew0KICAgICAgICAgICBMT0dfREVCVUcoImNoZWNrTE9DSyBmYWlsZWQ6
ICVzIiwgUFFlcnJvck1lc3NhZ2UoY29ubikpOw0KICAgICAgICAgICBQUWNsZWFyKGNoZWNrTE9D
S19yZXMpOw0KICAgICAgICAgICByZXR1cm47DQogICAgICAgIH0NCg0KICAgICAgICBuRmllbGRz
ID0gUFFuZmllbGRzKGNoZWNrTE9DS19yZXMpOw0KICAgICAgICBuVHVwbGVzID0gUFFudHVwbGVz
KGNoZWNrTE9DS19yZXMpOw0KDQoJaWYoblR1cGxlcyA+IDApDQoJew0KCQlMT0dfREVCVUcoIiVz
KCkgZmEoJWkpKCUwOFgpIGlzIGN1cnJlbnRseSBMT0NLRUQgYnkgUElEICVzIGFzIGNsYXNzaWQ9
JXMgb2JqaWQ9JXMiLF9fZnVuY19fLGZhLGZhLFBRZ2V0dmFsdWUoY2hlY2tMT0NLX3JlcywwLDAp
LFBRZ2V0dmFsdWUoY2hlY2tMT0NLX3JlcywwLDEpLFBRZ2V0dmFsdWUoY2hlY2tMT0NLX3Jlcyww
LDIpKTsNCiAgICAgICAgCVBRY2xlYXIoY2hlY2tMT0NLX3Jlcyk7DQoJCS8vcHJpbnRMT0NLUygp
Ow0KCX0NCgllbHNlDQoJew0KCQlMT0dfREVCVUcoIiVzKCkgZmEoJWkpKCUwOFgpIGlzIE5PVCBM
T0NLRUQiLF9fZnVuY19fLGZhLGZhKTsNCiAgICAgICAgCVBRY2xlYXIoY2hlY2tMT0NLX3Jlcyk7
DQoJfQ0KDQp9
--000000000000f82bda06253b4423--