| From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Nishant Sharma <nishant(dot)sharma(at)enterprisedb(dot)com> |
| Cc: | Shruthi Gowda <gowdashru(at)gmail(dot)com>, Mahendra Singh Thalor <mahi6run(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL |
| Date: | 2026-05-05 20:00:00 |
| Message-ID: | 75460b3c-255d-47eb-b889-d99de38e6758@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello hackers,
01.05.2026 22:20, Andrew Dunstan wrote:
>
> On Wed, Apr 22, 2026 at 12:27 AM Nishant Sharma <nishant(dot)sharma(at)enterprisedb(dot)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(at)entry=45, c=c(at)entry=ECPG_COMPAT_PGSQL,
con=con(at)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(at)entry=45, c=c(at)entry=ECPG_COMPAT_PGSQL,
con=con(at)entry=0x747888000ca0, prev=0x0, this=0x74788800ad40)
at prepare.c:313
#1 0x00007478ad3a8a32 in ECPGprepare (lineno=lineno(at)entry=45, connection_name=connection_name(at)entry=0x0,
questionmarks=questionmarks(at)entry=false,
name=name(at)entry=0x5d934a41b024 "i", variable=variable(at)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(at)entry=0x7962f4000d60, errmsgp=errmsgp(at)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(at)entry=0x7962f4000d60, errmsgp=errmsgp(at)entry=0x7963151ffbd0) at fe-exec.c:1226
#1 0x00007963188e9d44 in getAnotherTuple (conn=conn(at)entry=0x7962f4000d60, msgLength=14) at fe-protocol3.c:849
#2 0x00007963188eb42b in pqParseInput3 (conn=conn(at)entry=0x7962f4000d60) at fe-protocol3.c:388
#3 0x00007963188e0e69 in parseInput (conn=conn(at)entry=0x7962f4000d60) at fe-exec.c:2039
#4 0x00007963188e3d74 in PQgetResult (conn=conn(at)entry=0x7962f4000d60) at fe-exec.c:2125
#5 0x00007963188e3fec in PQexecStart (conn=conn(at)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(at)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(at)entry=45, compat=compat(at)entry=0, force_indicator=force_indicator(at)entry=1,
connection_name=connection_name(at)entry=0x0, questionmarks=questionmarks(at)entry=false, st=st(at)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | SATYANARAYANA NARLAPURAM | 2026-05-05 20:05:51 | Re: Changing the state of data checksums in a running cluster |
| Previous Message | SATYANARAYANA NARLAPURAM | 2026-05-05 19:45:09 | Re: Changing the state of data checksums in a running cluster |