Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL

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

In response to

Responses

Browse pgsql-hackers by date

  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