Обсуждение: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
[BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Hi,
The ECPG application crashes with a segmentation fault when calling specific deallocation or prepared statement functions without an established database connection. This is caused by a missing NULL check on the connection handle before attempting to access it.
The issue is reproducible on the MASTER branch and affects older versions up to v13.
The issue can be reproduced by modifying existing test cases, such as src/interfaces/ecpg/test/sql/execute.pgc or src/interfaces/ecpg/test/sql/desc.pgc. The general method is to skip the EXEC SQL CONNECT statement (or intentionally force the connection to fail).
To specifically isolate the crash in ECPGdeallocate_all() and prevent the program from hitting the ECPGprepared_statement() crash first, modify the desc.pgc test file by moving the EXEC SQL DEALLOCATE ALL statement to an earlier point
Seg fault in ECPGprepared_statement():[434574]: ECPGdebug: set to 1
[434574]: ECPGconnect: opening database ecpg1_regression on <DEFAULT> port <DEFAULT>
[434574]: ECPGconnect: connection to server on socket "/tmp/.s.PGSQL.5444" failed: FATAL: database "ecpg1_regression" does not exist
[434574]: ecpg_finish: connection main closed
[434574]: raising sqlcode -402 on line 24: could not connect to database "ecpg1_regression" on line 24
SQL error: could not connect to database "ecpg1_regression" on line 24
[434574]: raising sqlcode -220 on line 25: connection "NULL" does not exist on line 25
SQL error: connection "NULL" does not exist on line 25
[434574]: raising sqlcode -220 on line 26: connection "NULL" does not exist on line 26
SQL error: connection "NULL" does not exist on line 26
[434574]: raising sqlcode -220 on line 29: connection "NULL" does not exist on line 29
SQL error: connection "NULL" does not exist on line 29
[434574]: raising sqlcode -220 on line 32: connection "NULL" does not exist on line 32
SQL error: connection "NULL" does not exist on line 32
[434574]: raising sqlcode -220 on line 35: connection "NULL" does not exist on line 35
SQL error: connection "NULL" does not exist on line 35
Inserted 0 tuples via execute immediate
[434574]: raising sqlcode -220 on line 40: connection "NULL" does not exist on line 40
SQL error: connection "NULL" does not exist on line 40
[434574]: raising sqlcode -220 on line 41: connection "NULL" does not exist on line 41
SQL error: connection "NULL" does not exist on line 41
Inserted 0 tuples via prepared execute
[434574]: raising sqlcode -220 on line 45: connection "NULL" does not exist on line 45
SQL error: connection "NULL" does not exist on line 45
[434574]: raising sqlcode -220 on line 49: connection "NULL" does not exist on line 49
SQL error: connection "NULL" does not exist on line 49
Program received signal SIGSEGV, Segmentation fault.
0x0000fffff7f92654 in ecpg_find_prepared_statement (name=0xaaaaaaaa1aa8 "f", con=0x0, prev_=0x0) at prepare.c:277
277 for (this = con->prep_stmts, prev = NULL;
(gdb) bt
#0 0x0000fffff7f92654 in ecpg_find_prepared_statement (name=0xaaaaaaaa1aa8 "f", con=0x0, prev_=0x0) at prepare.c:277
#1 0x0000fffff7f92aa8 in ecpg_prepared (name=0xaaaaaaaa1aa8 "f", con=0x0) at prepare.c:393
#2 0x0000fffff7f92afc in ECPGprepared_statement (connection_name=0x0, name=0xaaaaaaaa1aa8 "f", lineno=53)
at prepare.c:404
#3 0x0000aaaaaaaa0f74 in main () at /home/shrkc/work/postgres/inst/bin/execute.pgc:52
Seg fault in ECPGdeallocate_all() :
Program received signal SIGSEGV, Segmentation fault.
0x0000fffff7f92a2c in ecpg_deallocate_all_conn (lineno=25, c=ECPG_COMPAT_PGSQL, con=0x0) at prepare.c:372
372 while (con->prep_stmts)
(gdb) bt
#0 0x0000fffff7f92a2c in ecpg_deallocate_all_conn (lineno=25, c=ECPG_COMPAT_PGSQL, con=0x0) at prepare.c:372
#1 0x0000fffff7f92a78 in ECPGdeallocate_all (lineno=25, compat=0, connection_name=0x0) at prepare.c:384
#2 0x0000aaaaaaaa0e60 in main () at /home/shrkc/work/postgres/inst/bin/desc.pgc:25
Please find the proposed patch attached below for your review.
Thanks & Regards,
Shruthi K C
EnterpriseDB: http://www.enterprisedb.com
Вложения
Shruthi Gowda <gowdashru@gmail.com> writes:
> The ECPG application crashes with a segmentation fault when calling
> specific deallocation or prepared statement functions without an
> established database connection. This is caused by a missing NULL check on
> the connection handle before attempting to access it.
Hmm ... poking around, I see several other places that aren't checking
the result of ecpg_get_connection. Shouldn't we tighten them all?
regards, tom lane
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Shruthi Gowda <gowdashru@gmail.com> writes:
> The ECPG application crashes with a segmentation fault when calling
> specific deallocation or prepared statement functions without an
> established database connection. This is caused by a missing NULL check on
> the connection handle before attempting to access it.
Hmm ... poking around, I see several other places that aren't checking
the result of ecpg_get_connection. Shouldn't we tighten them all?
regards, tom lane
ecpg_get_connection() and noted that, in most instances, it is followed by ecpg_init(), which validates the connection and returns immediately if the connection is NULL.Вложения
On Thu, Jan 8, 2026 at 3:00 AM Shruthi Gowda <gowdashru@gmail.com> wrote:
>
>
> On Mon, Dec 8, 2025 at 9:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Shruthi Gowda <gowdashru@gmail.com> writes:
>> > The ECPG application crashes with a segmentation fault when calling
>> > specific deallocation or prepared statement functions without an
>> > established database connection. This is caused by a missing NULL check on
>> > the connection handle before attempting to access it.
>>
>> Hmm ... poking around, I see several other places that aren't checking
>> the result of ecpg_get_connection. Shouldn't we tighten them all?
>>
>> regards, tom lane
>
>
> I agree. I’ve reviewed all occurrences of ecpg_get_connection() and noted that, in most instances, it is followed by
ecpg_init(),which validates the connection and returns immediately if the connection is NULL.
Why did you add this check instead of calling ecpg_init()?
Wouldn't it be better and sufficient to use ecpg_init() to validate
the connection?
+ con = ecpg_get_connection(connection_name);
+ if (!con)
+ {
+ ecpg_raise(lineno, ECPG_NO_CONN, ECPG_SQLSTATE_CONNECTION_DOES_NOT_EXIST,
+ connection_name ? connection_name : ecpg_gettext("NULL"));
Regards,
--
Fujii Masao
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
On Thu, Jan 8, 2026 at 3:00 AM Shruthi Gowda <gowdashru@gmail.com> wrote:
>
>
> On Mon, Dec 8, 2025 at 9:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Shruthi Gowda <gowdashru@gmail.com> writes:
>> > The ECPG application crashes with a segmentation fault when calling
>> > specific deallocation or prepared statement functions without an
>> > established database connection. This is caused by a missing NULL check on
>> > the connection handle before attempting to access it.
>>
>> Hmm ... poking around, I see several other places that aren't checking
>> the result of ecpg_get_connection. Shouldn't we tighten them all?
>>
>> regards, tom lane
>
>
> I agree. I’ve reviewed all occurrences of ecpg_get_connection() and noted that, in most instances, it is followed by ecpg_init(), which validates the connection and returns immediately if the connection is NULL.
Why did you add this check instead of calling ecpg_init()?
Wouldn't it be better and sufficient to use ecpg_init() to validate
the connection?
+ con = ecpg_get_connection(connection_name);
+ if (!con)
+ {
+ ecpg_raise(lineno, ECPG_NO_CONN, ECPG_SQLSTATE_CONNECTION_DOES_NOT_EXIST,
+ connection_name ? connection_name : ecpg_gettext("NULL"));
ecpg_init() is a more consistent approach and aligns with how this is handled in other parts of the code. ecpg_init() for validation. Please find the revised version attached.Вложения
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
On Mon, 19 Jan 2026 at 17:38, Shruthi Gowda <gowdashru@gmail.com> wrote:
>
>
>
> On Thu, Jan 8, 2026 at 9:32 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>>
>> On Thu, Jan 8, 2026 at 3:00 AM Shruthi Gowda <gowdashru@gmail.com> wrote:
>> >
>> >
>> > On Mon, Dec 8, 2025 at 9:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >>
>> >> Shruthi Gowda <gowdashru@gmail.com> writes:
>> >> > The ECPG application crashes with a segmentation fault when calling
>> >> > specific deallocation or prepared statement functions without an
>> >> > established database connection. This is caused by a missing NULL check on
>> >> > the connection handle before attempting to access it.
>> >>
>> >> Hmm ... poking around, I see several other places that aren't checking
>> >> the result of ecpg_get_connection. Shouldn't we tighten them all?
>> >>
>> >> regards, tom lane
>> >
>> >
>> > I agree. I’ve reviewed all occurrences of ecpg_get_connection() and noted that, in most instances, it is followed
byecpg_init(), which validates the connection and returns immediately if the connection is NULL.
>>
>> Why did you add this check instead of calling ecpg_init()?
>> Wouldn't it be better and sufficient to use ecpg_init() to validate
>> the connection?
>>
>> + con = ecpg_get_connection(connection_name);
>> + if (!con)
>> + {
>> + ecpg_raise(lineno, ECPG_NO_CONN, ECPG_SQLSTATE_CONNECTION_DOES_NOT_EXIST,
>> + connection_name ? connection_name : ecpg_gettext("NULL"));
>>
>
> Thanks for the feedback, Fujii. I agree—using ecpg_init() is a more consistent approach and aligns with how this is
handledin other parts of the code.
> I have updated the patch to use ecpg_init() for validation. Please find the revised version attached.
> The patch works for MASTER and all the back branches.
>
> Thanks & Regards,
>
> Shruthi K C
>
> EnterpriseDB: http://www.enterprisedb.com
Thanks Shruthi for the updated patch.
Please add a crash test case in your patch. If possible, please add a
test for connection=NULL for ECPGdeallocate_all,
ECPGprepared_statement and ECPGget_desc.
--
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Here are some review comments on v3 patch:-
Change in descriptor.c file - In my opinion, we can use `if(conn)` with ecpg_raise, like other occurrence of ecpg_get_connection() call check in this file, and not using ecpg_init(). Three reasons: a) Consistency in checking conn after ecpg_get_connection() call in this file with if check. b) We don't need to remove 'ecpg_init_sqlca(sqlca);' line due to call to ecpg_init(). c) #2 comment below.
If you agree with #1, then I see many other reasons for which ECPGget_desc() returns and we can avoid ecpg_get_connection() call at top of that function for those reasons and keep the check at the required location only instead of moving at top of the function.
I see there is one more location of ecpg_get_connection() call where there is no check of NULL conn. In function ecpg_freeStmtCacheEntry() of file prepare.c? I understand it's not required for a call in ecpg_auto_prepare(), as the caller already validated that connection string. But I think, conn in ecpg_freeStmtCacheEntry() is different from the one that was validated.
+1 to Mahindra, new test cases specific to the crash required for this change?