Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wKLw8-000syL-0G for pgsql-hackers@arkaria.postgresql.org; Tue, 05 May 2026 20:00:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wKLw6-00DiPd-2L for pgsql-hackers@arkaria.postgresql.org; Tue, 05 May 2026 20:00:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wKLw6-00DiPV-0a for pgsql-hackers@lists.postgresql.org; Tue, 05 May 2026 20:00:06 +0000 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wKLw3-00000000NAM-1w0B for pgsql-hackers@postgresql.org; Tue, 05 May 2026 20:00:05 +0000 Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-43d76dd4ee8so4541737f8f.2 for ; Tue, 05 May 2026 13:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778011202; x=1778616002; darn=postgresql.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=B0EKNGPvdPsXSE/VINZ9E3UX++xHc4cY6vUgLAgTpn0=; b=oCW1R/cL6UI7pvN+qgnoHSQKdHb5GidcS24zVqUeMxt4tT0kZaE+i908aVDfAl18z8 gbra8IXKnzAPGCpNwKMUQ75/hGgQH2eFVhrTwivfZN+r0FmVOc7kLOEZV4H3t9kKUrxN s1BYhAF7wIKQJAvh+6LaKieXXozWXvJtzxjjvOz6xHGGSOveYO4kUiZPvKP9m8EfAop7 csGFxptUAstugic5ty28HnUFSduBL+Gn3MPHX4WFYh3VEGrBI4tqQUAX785D2S7AP7jk Xx/Yp12/BBgfblctBuwj9JwLcpo2go/3St9X6iP0WTZpvBQ136wdgZw4IE/jesGy2Qj1 rXIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778011202; x=1778616002; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=B0EKNGPvdPsXSE/VINZ9E3UX++xHc4cY6vUgLAgTpn0=; b=eLIEjXiaAXzzy4XDIh1ms3K50+g/GN8i5PL+HjQ/GnDyj5lG2g4bEiVDYvD5lMAqJY /uxePcSi3CPgP5OktDqG0U/sMpikaHMsVY0ziSFQDCu2M74dw1vouyNu3cgJ8bBFc21Q e9Qd2ZswJYZggDXDoNqPBdA3lU+kAkjccNwKM86dzoN4Ee5/zxidVCjTmih29xXBE/YR F8O/tJuu0HH4nQ3o17w2hav9GCv3hp0Lh6CQR/pDgOsyUCNtKClgVh+CaUE2XNoQYFO4 se8VVXlx43DEOCxSnuhgKuhexJBw78aKgp4I8IYLgA06sNi/oiAD4zTMQunqkBw+5dp0 EaNw== X-Forwarded-Encrypted: i=1; AFNElJ/qkK5KH+64nmHBttwCpNG2nBT+1E+QbkdyRSfNFCLCB/lOBTKVHXymJmvb1LjKyAZXNWPry1uIDXJHuWCS@postgresql.org X-Gm-Message-State: AOJu0YzzFoHQDlavYGyxDf8qO7fZI8hAwJJac/oqq9exOUG4gZGEWC4S t91BuW+CT4s8babI/vNE2c6saVC19oLmHZrQ9EOhugNlr4NTIhI2GfoZ X-Gm-Gg: AeBDietaCSGahdYGT7RYLBEYjPae6uJJUSRuJ67I1Dj/qAwYmqZJjQm0kJgNv1WQlfk uyDAahqBWHU2mqLSZ3eu29D/7zgRFa5iBOmnJrRXF6Hvs1SBbxT9PRQ5aS7mMt9ZDnYdnP60h+7 JdUGl42BKL40VNzKExg6EwU39zZtZwGWK3CLACvqnNgyjYmPfWv+J7G+QpVHW6Z8Pr4MEDSTOew PYSq0Q9AXbURrqiqIE1yHG5lpWujg8eXHtuTAODYpDAiPGvd8Yxsel7OTTnfP23skX5F92ORdIS 9AfpcBDmdtJtOedFyMX/03G63svOT3lSZiFkkzmqSIUOMolSbzJJLSwFM8Q7lMtjIQeqjr/7PLP QC6r0DHAKLiUIchm6AjdqLOCghAOKEaqTWTDs5BFKXfpHIGhfuve/b2GJbNzE3R4liqeFu32fom waINt0j+aFnXzLfQnnr1iGVBrFof7cAsn/973fSgK/1VeTYQ== X-Received: by 2002:a05:6000:2c01:b0:43b:5b25:67f8 with SMTP id ffacd0b85a97d-4515ce1c515mr806904f8f.20.1778011202358; Tue, 05 May 2026 13:00:02 -0700 (PDT) Received: from [192.168.0.50] ([89.149.68.143]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45055960902sm7573948f8f.28.2026.05.05.13.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 May 2026 13:00:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------6D9C0SRi0ujMS4AUyrRF3Grb" Message-ID: <75460b3c-255d-47eb-b889-d99de38e6758@gmail.com> Date: Tue, 5 May 2026 23:00:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL To: Andrew Dunstan , Nishant Sharma Cc: Shruthi Gowda , Mahendra Singh Thalor , Fujii Masao , Tom Lane , PostgreSQL Development References: Content-Language: en-US From: Alexander Lakhin In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------6D9C0SRi0ujMS4AUyrRF3Grb Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello hackers, 01.05.2026 22:20, Andrew Dunstan wrote: > > On Wed, Apr 22, 2026 at 12:27 AM Nishant Sharma 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=) at .../src/interfaces/ecpg/test/thread/prep.pgc:45 #3  0x00007478ad09caa4 in start_thread (arg=) 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=, compat=, force_indicator=, connection_name=,     questionmarks=questionmarks@entry=false, st=, 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=) at .../src/interfaces/ecpg/test/thread/alloc.pgc:45 #11 0x000079631869caa4 in start_thread (arg=) 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 --------------6D9C0SRi0ujMS4AUyrRF3Grb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hello hackers,

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
--------------6D9C0SRi0ujMS4AUyrRF3Grb--