Horton

Thread

Commits

  1. Avoid ecpglib core dump with out-of-order operations.

  1. BUG #17514: Application with embedded SQL crashes when executing EXEC SQL PREPARE

    The Post Office <noreply@postgresql.org> — 2022-06-09T06:40:28Z

    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

  2. Re: BUG #17514: Application with embedded SQL crashes when executing EXEC SQL PREPARE

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-06-09T17:01:36Z

    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

  3. RE: BUG #17514: Application with embedded SQL crashes when executing EXEC SQL PREPARE

    okano.naoki@fujitsu.com <okano.naoki@fujitsu.com> — 2022-06-10T05:09:19Z

    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

  4. Re: BUG #17514: Application with embedded SQL crashes when executing EXEC SQL PREPARE

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-06-14T22:18:08Z

    "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