Обсуждение: [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?
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?
Regards,Nishant Sharma,EDB, Pune.
Thanks, Nishant, for the review. I agree with points 1 and 2 and have revised the patch accordingly. Regarding point 3, you are correct; the conn in ecpg_freeStmtCacheEntry() differs from the one validated in the caller. I have now added the necessary validation in the latest version.
I have also included a test case patch covering all execution paths except for the ecpg_freeStmtCacheEntry() flow. I was unable to trigger that specific flow, and it appears none of the existing test cases cover that line either.
Вложения
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
1. I think we should rename "test_null_connection.pgc" to "test6.pgc", and make other required changes appropriately. We can see existing test files uses test1.pgc, test2.pgc ..., test5.pgc as naming convention, and has test description inside the file.
2. No need to add test_null_connection.c as commit file in src/interfaces/ecpg/test/connect/ folder, we don't see such C src files for other existing test files like test1.c, test2.c ..., test5.c. It is part of src/interfaces/ecpg/test/connect/.gitignore. So, need to add test6.c and its executable test6 like others in src/interfaces/ecpg/test/connect/.gitignore
3. After doing #2 above make sure to create the test9.c C src file as src/interfaces/ecpg/test/expected/connect-test6.c, I can see other existing connect tests C src files in src/interfaces/ecpg/test/expected/ folder.
3. Not able to run "make -j 8 installcheck" on my setup, fails due to #3.
4. Extra space at the end (don't see that in other tested cases prints) : printf("Test 1: Try to get descriptor on a disconnected connection \n");
5. char *query = "SELECT 1" -- unused in new test file added.
6. "if (stmt.connection == NULL)" --> "if (!stmt.connection)"?
7. Should we return -1 in else of new fix added in ecpg_freeStmtCacheEntry()? If 'con' is NULL, why clean up the cache? Is returning -1 more defensive than cleaning the cache?
8. Do we need to clean up "stmt.oldlocale = ecpg_strdup(...)" and undo setlocale() before returning from the newly added fix in ECPGget_desc()?
On Tue, Mar 24, 2026 at 11:29 AM Nishant Sharma <nishant.sharma@enterprisedb.com> wrote: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?
Regards,Nishant Sharma,EDB, Pune.Thanks, Nishant, for the review. I agree with points 1 and 2 and have revised the patch accordingly. Regarding point 3, you are correct; the
conninecpg_freeStmtCacheEntry()differs from the one validated in the caller. I have now added the necessary validation in the latest version.I have also included a test case patch covering all execution paths except for the
ecpg_freeStmtCacheEntry()flow. I was unable to trigger that specific flow, and it appears none of the existing test cases cover that line either.
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Thanks Shruthi, for the new patches!Here are some review comments:-
1. I think we should rename "test_null_connection.pgc" to "test6.pgc", and make other required changes appropriately. We can see existing test files uses test1.pgc, test2.pgc ..., test5.pgc as naming convention, and has test description inside the file.
2. No need to add test_null_connection.c as commit file in src/interfaces/ecpg/test/connect/ folder, we don't see such C src files for other existing test files like test1.c, test2.c ..., test5.c. It is part of src/interfaces/ecpg/test/connect/.gitignore. So, need to add test6.c and its executable test6 like others in src/interfaces/ecpg/test/connect/.gitignore
3. After doing #2 above make sure to create the test9.c C src file as src/interfaces/ecpg/test/expected/connect-test6.c, I can see other existing connect tests C src files in src/interfaces/ecpg/test/expected/ folder.
3. Not able to run "make -j 8 installcheck" on my setup, fails due to #3.
4. Extra space at the end (don't see that in other tested cases prints) : printf("Test 1: Try to get descriptor on a disconnected connection \n");
5. char *query = "SELECT 1" -- unused in new test file added.
6. "if (stmt.connection == NULL)" --> "if (!stmt.connection)"?
7. Should we return -1 in else of new fix added in ecpg_freeStmtCacheEntry()? If 'con' is NULL, why clean up the cache? Is returning -1 more defensive than cleaning the cache?
8. Do we need to clean up "stmt.oldlocale = ecpg_strdup(...)" and undo setlocale() before returning from the newly added fix in ECPGget_desc()?Regards,Nishant Sharma,EDB, Pune.On Thu, Apr 9, 2026 at 4:14 PM Shruthi Gowda <gowdashru@gmail.com> wrote:On Tue, Mar 24, 2026 at 11:29 AM Nishant Sharma <nishant.sharma@enterprisedb.com> wrote: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?
Regards,Nishant Sharma,EDB, Pune.Thanks, Nishant, for the review. I agree with points 1 and 2 and have revised the patch accordingly. Regarding point 3, you are correct; the
conninecpg_freeStmtCacheEntry()differs from the one validated in the caller. I have now added the necessary validation in the latest version.I have also included a test case patch covering all execution paths except for the
ecpg_freeStmtCacheEntry()flow. I was unable to trigger that specific flow, and it appears none of the existing test cases cover that line either.
7. Should we return -1 in else of new fix added in ecpg_freeStmtCacheEntry()? If 'con' is NULL, why clean up the cache? Is returning -1 more defensive than cleaning the cache?
- Memory must be freed to avoid leaks
- A disconnected connection means the entry is stale and must be cleaned
The NULL check protects against crashes while still performing necessary cleanup.
Вложения
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
I can apply v5 on all active branches (i.e master, REL_18, REL_17, REL_16, REL_15, REL_14).
I checked PG's ECPG regression with v5 and v2_test on master, REL_18, REL_17, and REL_16 using both make and meson.
The v5 patch looks good to me now. I only have a few observations on v2_test patch.
Review comments on v2_test:
1. Not able to apply the v2 test patch on PG15 and PG14 branch, appears meson.build for test is not there on these branches. Need to remove all meson related changes for these branches.
2. char val2[5] = "data1"; --> val2's size will not be able to fit '\0' for the string. As size of val2 and number of characters in "data1" are exactly same?
3. "exec sql disconnect;" - Do we need this at the end as we have already disconnected before Test 2.
3. Minor - Do we need "printf("sqlca.sqlcode = %ld\n", sqlca.sqlcode);"? I see all others have it, but not Test 4?
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Thanks Shruthi for the new patches!
I can apply v5 on all active branches (i.e master, REL_18, REL_17, REL_16, REL_15, REL_14).
I checked PG's ECPG regression with v5 and v2_test on master, REL_18, REL_17, and REL_16 using both make and meson.
The v5 patch looks good to me now. I only have a few observations on v2_test patch.
Review comments on v2_test:
1. Not able to apply the v2 test patch on PG15 and PG14 branch, appears meson.build for test is not there on these branches. Need to remove all meson related changes for these branches.
2. char val2[5] = "data1"; --> val2's size will not be able to fit '\0' for the string. As size of val2 and number of characters in "data1" are exactly same?
3. "exec sql disconnect;" - Do we need this at the end as we have already disconnected before Test 2.
3. Minor - Do we need "printf("sqlca.sqlcode = %ld\n", sqlca.sqlcode);"? I see all others have it, but not Test 4?Regards,Nishant Sharma,Pune, EDB.
Вложения
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Thanks Shruthi for the new test patches!I can apply v3_test_v15 on both REL_15 and REL_14.I only have the following concern in the test patches now:-1. The test1 table in the test case is not being cleaned up.Regards,Nishant Sharma,EDB, Pune.
Hi Nishant, I have updated the test patches by adding a ROLLBACK command before DISCONNECT. Please find the latest test patches for master through REL_16 (v4_test) and REL_15 through REL_14 (v4_test_v15).
I am also reattaching the v5 source code patch, which is applicable to all active branches (master, REL_18, REL_17, REL_16, REL_15, and REL_14).
Вложения
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Thanks Shruthi!v5 code, v4_test and v4_test_15 patches look good to me.I checked ECPG regression on master, REL_18, REL_17, REL_16, REL_15, REL_14 using both make and meson.I have finished my review work on the patches. Thank you!
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
01.05.2026 22:20, Andrew Dunstan wrote:
On Wed, Apr 22, 2026 at 12:27 AM Nishant Sharma <nishant.sharma@enterprisedb.com> wrote:Thanks Shruthi!v5 code, v4_test and v4_test_15 patches look good to me.I checked ECPG regression on master, REL_18, REL_17, REL_16, REL_15, REL_14 using both make and meson.I have finished my review work on the patches. Thank you!Thanks, everybody, pushed (as combined patches)
Despite this improvement committed, dikkop keeps producing segfaults
during ecpg test, e.g., [1], [2]:
ok 62 - thread/thread_implicit 224 ms
not ok 63 - thread/prep 116 ms
# (test process was terminated by signal 11: Segmentation fault)
ok 64 - thread/alloc 406 ms
There is no other useful information in the log, so it's not clear what's
wrong with that animal (no other gives us such failures), but I could
produce something similar (on FreeBSD and Linux) with:
echo "max_connections = 10" >/tmp/temp.config; TEMP_CONFIG=/tmp/temp.config gmake -s check -C src/interfaces/ecpg/test
not ok 64 - thread/prep 29 ms
# (test process was terminated by signal 11: Segmentation fault)
not ok 65 - thread/alloc 27 ms
# (test process was terminated by signal 11: Segmentation fault)
gdb src/interfaces/ecpg/test/thread/prep src/interfaces/ecpg/test/core.3371028
Core was generated by `.../src/interfaces/ecpg/test/thread/prep'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007478ad3a8301 in deallocate_one (lineno=lineno@entry=45, c=c@entry=ECPG_COMPAT_PGSQL, con=con@entry=0x747888000ca0, prev=0x0, this=0x74788800ad40)
at prepare.c:313
313 this->stmt->connection->connection,
[Current thread is 1 (Thread 0x7478a1c006c0 (LWP 3371041))]
(gdb) bt
#0 0x00007478ad3a8301 in deallocate_one (lineno=lineno@entry=45, c=c@entry=ECPG_COMPAT_PGSQL, con=con@entry=0x747888000ca0, prev=0x0, this=0x74788800ad40)
at prepare.c:313
#1 0x00007478ad3a8a32 in ECPGprepare (lineno=lineno@entry=45, connection_name=connection_name@entry=0x0, questionmarks=questionmarks@entry=false,
name=name@entry=0x5d934a41b024 "i", variable=variable@entry=0x7478a1bffdb0 "INSERT INTO T VALUES ( ? )") at prepare.c:264
#2 0x00005d934a41a536 in fn (arg=<optimized out>) at .../src/interfaces/ecpg/test/thread/prep.pgc:45
#3 0x00007478ad09caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#4 0x00007478ad129c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb) p this->stmt
$1 = (struct statement *) 0x242028205345554c
(gdb) p this->stmt->connection
Cannot access memory at address 0x2420282053455564
gdb src/interfaces/ecpg/test/thread/alloc src/interfaces/ecpg/test/core.3371068
Core was generated by `.../src/interfaces/ecpg/test/thread/alloc'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 pqRowProcessor (conn=conn@entry=0x7962f4000d60, errmsgp=errmsgp@entry=0x7963151ffbd0) at fe-exec.c:1226
1226 int nfields = res->numAttributes;
[Current thread is 1 (Thread 0x7963152006c0 (LWP 3371075))]
(gdb) bt
#0 pqRowProcessor (conn=conn@entry=0x7962f4000d60, errmsgp=errmsgp@entry=0x7963151ffbd0) at fe-exec.c:1226
#1 0x00007963188e9d44 in getAnotherTuple (conn=conn@entry=0x7962f4000d60, msgLength=14) at fe-protocol3.c:849
#2 0x00007963188eb42b in pqParseInput3 (conn=conn@entry=0x7962f4000d60) at fe-protocol3.c:388
#3 0x00007963188e0e69 in parseInput (conn=conn@entry=0x7962f4000d60) at fe-exec.c:2039
#4 0x00007963188e3d74 in PQgetResult (conn=conn@entry=0x7962f4000d60) at fe-exec.c:2125
#5 0x00007963188e3fec in PQexecStart (conn=conn@entry=0x7962f4000d60) at fe-exec.c:2386
#6 0x00007963188e40a7 in PQexec (conn=0x7962f4000d60, query=0x7962e8000ca0 "select relname from pg_class where relname = 'pg_class'") at fe-exec.c:2281
#7 0x0000796318948620 in ecpg_execute (stmt=0x7962e8009e60) at execute.c:1619
#8 0x00007963189494fc in ecpg_do (lineno=<optimized out>, compat=<optimized out>, force_indicator=<optimized out>, connection_name=<optimized out>,
questionmarks=questionmarks@entry=false, st=<optimized out>, query=0x5a5947b97028 "select relname from pg_class where relname = 'pg_class'",
args=0x7963151ffcf0) at execute.c:2273
#9 0x00007963189495b7 in ECPGdo (lineno=lineno@entry=45, compat=compat@entry=0, force_indicator=force_indicator@entry=1,
connection_name=connection_name@entry=0x0, questionmarks=questionmarks@entry=false, st=st@entry=0,
query=0x5a5947b97028 "select relname from pg_class where relname = 'pg_class'") at execute.c:2298
#10 0x00005a5947b963b8 in fn (arg=<optimized out>) at .../src/interfaces/ecpg/test/thread/alloc.pgc:45
#11 0x000079631869caa4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#12 0x0000796318729c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb) p conn
$1 = (PGconn *) 0x7962f4000d60
(gdb) p conn->result
$2 = (PGresult *) 0x0
Could you please look if such crashes can be prevented too?
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dikkop&dt=2026-05-04%2010%3A00%3A10
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dikkop&dt=2026-05-03%2021%3A25%3A17
Best regards,
Alexander
Alexander Lakhin <exclusion@gmail.com> writes:
> There is no other useful information in the log, so it's not clear what's
> wrong with that animal (no other gives us such failures), but I could
> produce something similar (on FreeBSD and Linux) with:
> echo "max_connections = 10" >/tmp/temp.config; TEMP_CONFIG=/tmp/temp.config gmake -s check -C
src/interfaces/ecpg/test
Yes, I can also reproduce problems with the ecpg tests at
max_connections = 10. For me, thread/prep segfaults but thread/alloc
just seems to hang indefinitely. (thread/prep sometimes does too.)
These issues are not new; v18 does the same. The reporting is a
bit different but I think that's from pg_regress changes not ecpg.
Looking at the postmaster log, I see
2026-05-05 16:11:06.509 EDT [682116] FATAL: sorry, too many clients already
which is unsurprising in this situation, but apparently these tests
don't handle a connection failure well at all.
There's no such message in dikkop's log, so that may be an unrelated problem.
BTW, reducing max_connections to 5 causes several other tests to fail,
but in unsurprising ways, like
# +SQL error: could not connect to database "ecpg1_regression" on line 107
# +SQL error: could not connect to database "ecpg1_regression" on line 107
# +SQL error: could not connect to database "ecpg1_regression" on line 107
# +SQL error: could not connect to database "ecpg1_regression" on line 107
regards, tom lane
Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
On 2026-05-05 Tu 4:32 PM, Tom Lane wrote: > Alexander Lakhin <exclusion@gmail.com> writes: >> There is no other useful information in the log, so it's not clear what's >> wrong with that animal (no other gives us such failures), but I could >> produce something similar (on FreeBSD and Linux) with: >> echo "max_connections = 10" >/tmp/temp.config; TEMP_CONFIG=/tmp/temp.config gmake -s check -C src/interfaces/ecpg/test > Yes, I can also reproduce problems with the ecpg tests at > max_connections = 10. For me, thread/prep segfaults but thread/alloc > just seems to hang indefinitely. (thread/prep sometimes does too.) > These issues are not new; v18 does the same. The reporting is a > bit different but I think that's from pg_regress changes not ecpg. > > Looking at the postmaster log, I see > > 2026-05-05 16:11:06.509 EDT [682116] FATAL: sorry, too many clients already > > which is unsurprising in this situation, but apparently these tests > don't handle a connection failure well at all. > > There's no such message in dikkop's log, so that may be an unrelated problem. > > BTW, reducing max_connections to 5 causes several other tests to fail, > but in unsurprising ways, like > > # +SQL error: could not connect to database "ecpg1_regression" on line 107 > # +SQL error: could not connect to database "ecpg1_regression" on line 107 > # +SQL error: could not connect to database "ecpg1_regression" on line 107 > # +SQL error: could not connect to database "ecpg1_regression" on line 107 > > > Ugh. I will do some digging. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com