Subject: Re: Assistance Required: Timeout or Buffer Overflow Issue in PostgreSQL Client Application

From: Igor Korot <[email-masked]>
Date: Thu, 24 Oct 2024 11:12:09 -0500

Hi,
Is this a complete backtrace?
Can you post a complete backtrace? We need to see if there is a reference
to your application code?

What language is it written in?
What operation this thread was performing?

Thank you.

On Thu, Oct 24, 2024 at 11:12 AM Sasmit Utkarsh <[email-masked]> wrote:
>
> 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 [email-masked][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 [email-masked][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 [email-masked][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

---

From: Sasmit Utkarsh <[email-masked]>
Date: Thu, 24 Oct 2024 21:42:19 +0530

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 [email-masked][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 [email-masked][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 [email-masked][966034]: *** buffer
overflow detected ***: terminated

*Stack Trace of Thread 966070:*

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.

Regards,
Sasmit Utkarsh
+91-7674022625

---

From: Sasmit Utkarsh <[email-masked]>
Date: Thu, 24 Oct 2024 22:33:22 +0530

Hi,

Please find the complete stack trace, the language is C and thread here was
just performing the operation of fetching records from the postgresDB using
SQL_get_tpf_rw() function for which I've also attached implementation here
as well

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)

                                                             #10
0x0000000008180269 get_tpf_rw (server)

                                                             #11
0x0000000008189e47 FINDC (server)

                                                             #12
0x000000000818cd20 FINWC (server)

                                                             #13
0x00000000f2d03778 _segKIP8 (kip8.so)

                                                             #14
0x000000000816ad0e call_segment (server)

                                                             #15
0x000000000816ba0b ENTRC (server)

                                                             #16
0x00000000f2d096ee _segKIP5 (kip5.so)

                                                             #17
0x000000000816ad0e call_segment (server)

                                                             #18
0x000000000816ba0b ENTRC (server)

                                                             #19
0x00000000f2d1722d _segKIP4 (kip4.so)

                                                             #20
0x000000000816ad0e call_segment (server)

                                                             #21
0x000000000816ba0b ENTRC (server)

                                                             #22
0x00000000f2d1dee1 _segKIPB (kipb.so)

                                                             #23
0x000000000816ad0e call_segment (server)

                                                             #24
0x000000000816c454 ENTNC (server)

                                                             #25
0x00000000f2d2be54 _segKIP9 (kip9.so)

                                                             #26
0x000000000816ad0e call_segment (server)

                                                             #27
0x00000000081c264d call_appl_entry (server)

                                                             #28
0x000000000807f227 extest (server)

                                                             #29
0x000000000808923f handle_COMMS_TYPE_FUNCTIONAL_MESSAGE (server)

                                                             #30
0x000000000808d849 handle_comms_message (server)

                                                             #31
0x00000000f77d6e41 worker (libuv.so.1)

                                                             #32
0x00000000f78ff67a _ZL17asan_thread_startPv (libasan.so.8)

                                                             #33
0x00000000f6b170ad start_thread (libc.so.6)

                                                             #34
0x00000000f6bb1dea __clone (libc.so.6)
Regards,
Sasmit Utkarsh
+91-7674022625

On Thu, Oct 24, 2024 at 9:47 PM Igor Korot <[email-masked]> wrote:

> > 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:
> > 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.
> >