Обсуждение: BUG #17514: Application with embedded SQL crashes when executing EXEC SQL PREPARE

The following bug has been logged on the website:

Bug reference:      17514
Logged by:          Okano Naoki
Email address:      okano.naoki@jp.fujitsu.com
PostgreSQL version: 12.9
Operating system:   RHEL 7
Description:

Hi, 

Application with embedded SQL crashes with segmentation fault if I execute
EXEC SQL PREPARE
command before executing EXEC SQL CONNECT command (*1).
I know that it is the correct operation to execute EXEC SQL CONNECT command
first 
and then execute EXEC SQL PREPARE command.
But I expect this wrong operation to result in an error, not a crash.
Is it correct that this operation causes the application to crash? Or is it
a bug?

[Environment]
* OS version: RHEL 7
* PostgreSQL version: 12
  I checked that PostgreSQL 10 and 14 also occurred a same issue.

(*1) Here is an exapmle.
int
main(void)
{
  EXEC SQL BEGIN DECLARE SECTION;
    char *connection = "tcp:postgresql://localhost/postgres";
    char *user = "user_name";
  EXEC SQL END DECLARE SECTION;

  ECPGdebug(1, stderr);

  /* Skip a CONNECT command deliberately. */
  /* EXEC SQL CONNECT TO :connection USER :user; */

  EXEC SQL PREPARE stmt1 FROM "SELECT * FROM pg_database WHERE oid = ?";
  return (0);
}


The following is a backtrace of the coredump.
(gdb) bt
#0  0x00007f9b4d4da150 in parseInput () from
/opt/rh/rh-postgresql12/root/usr//lib64/libpq.so.rh-postgresql12-5
#1  0x00007f9b4d4dc60d in PQgetResult () from
/opt/rh/rh-postgresql12/root/usr//lib64/libpq.so.rh-postgresql12-5
#2  0x00007f9b4d4dc8cf in PQexecStart () from
/opt/rh/rh-postgresql12/root/usr//lib64/libpq.so.rh-postgresql12-5
#3  0x00007f9b4d4dcb6c in PQprepare () from
/opt/rh/rh-postgresql12/root/usr//lib64/libpq.so.rh-postgresql12-5
#4  0x00007f9b4dd01a61 in prepare_common () from
/opt/rh/rh-postgresql12/root/usr//lib64/libecpg.so.rh-postgresql12-6
#5  0x00007f9b4dd01fb5 in ECPGprepare () from
/opt/rh/rh-postgresql12/root/usr//lib64/libecpg.so.rh-postgresql12-6
#6  0x0000000000400a79 in main ()

Thanks in advance.

Regards,
Naoki Okano

PG Bug reporting form <noreply@postgresql.org> writes:
> Application with embedded SQL crashes with segmentation fault if I execute
> EXEC SQL PREPARE
> command before executing EXEC SQL CONNECT command (*1).
> I know that it is the correct operation to execute EXEC SQL CONNECT command
> first 
> and then execute EXEC SQL PREPARE command.
> But I expect this wrong operation to result in an error, not a crash.

We could do something like the attached, perhaps.  Having said that,
an application that includes no error checks is pretty unlikely to
fail gracefully :-(.

            regards, tom lane

diff --git a/src/interfaces/ecpg/ecpglib/connect.c b/src/interfaces/ecpg/ecpglib/connect.c
index 8dfcabe3b5..90f2ba9701 100644
--- a/src/interfaces/ecpg/ecpglib/connect.c
+++ b/src/interfaces/ecpg/ecpglib/connect.c
@@ -40,6 +40,8 @@ ecpg_get_connection_nr(const char *connection_name)
     if ((connection_name == NULL) || (strcmp(connection_name, "CURRENT") == 0))
     {
 #ifdef ENABLE_THREAD_SAFETY
+        ecpg_pthreads_init();    /* ensure actual_connection_key is valid */
+
         ret = pthread_getspecific(actual_connection_key);

         /*
@@ -78,6 +78,8 @@ ecpg_get_connection(const char *connection_name)
     if ((connection_name == NULL) || (strcmp(connection_name, "CURRENT") == 0))
     {
 #ifdef ENABLE_THREAD_SAFETY
+        ecpg_pthreads_init();    /* ensure actual_connection_key is valid */
+
         ret = pthread_getspecific(actual_connection_key);

         /*

Tom Lane wrote:
> We could do something like the attached, perhaps.  Having said that,
> an application that includes no error checks is pretty unlikely to
> fail gracefully :-(.

Thank you for replying and creating the patch!

I applied this patch to the master branch, and confirmed that the
application resulted in an error instead of a crash.
As with PREPARE, executing DISCONNECT CURRENT also caused the
application to crash, but this patch has fixed that.
The patch looks good to me.
I agree that applications should consider EXEC SQL PREPARE
returning errors.

Regards,
Naoki Okano

"okano.naoki@fujitsu.com" <okano.naoki@fujitsu.com> writes:
> I applied this patch to the master branch, and confirmed that the 
> application resulted in an error instead of a crash.
> As with PREPARE, executing DISCONNECT CURRENT also caused the 
> application to crash, but this patch has fixed that.
> The patch looks good to me.

Pushed then, thanks for testing!

(Note that this will appear in the August releases, not in this
week's 14.4 release.)

            regards, tom lane