MIME-Version: 1.0
References: 
 <CAASxf_P1F75Ck+0qyb10auT+BORupOM4yigXBnm7aWRNx1LYcA@mail.gmail.com>
 <3007317.1765210195@sss.pgh.pa.us>
 <CAASxf_P5f=Frf8S7rN9BzphtCLoeN9vFuh-V7ukotOQZU54g+w@mail.gmail.com>
 <CAHGQGwHAPXexiGaHMkDDRF7cPBr_3fgCNdT4n2+1UjaEU++BAQ@mail.gmail.com>
 <CAASxf_OGWD7PA5TMEh2MdF2YxN8V3ByLhnFJ=uw0hKr33sgqAw@mail.gmail.com>
In-Reply-To: 
 <CAASxf_OGWD7PA5TMEh2MdF2YxN8V3ByLhnFJ=uw0hKr33sgqAw@mail.gmail.com>
From: Mahendra Singh Thalor <mahi6run@gmail.com>
Date: Tue, 24 Mar 2026 08:04:01 +0530
Message-ID: 
 <CAKYtNAqjJbzV+ZJDqA-s0fHSLen6msc=A0SfrTS1ub1KKH9haQ@mail.gmail.com>
Subject: Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all()
 when connection is NULL
To: Shruthi Gowda <gowdashru@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	PostgreSQL Development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAKYtNAqjJbzV%2BZJDqA-s0fHSLen6msc%3DA0SfrTS1ub1KKH9haQ%40mail.gmail.com>
Precedence: bulk

On Mon, 19 Jan 2026 at 17:38, Shruthi Gowda <gowdashru@gmail.com> wrote:
>
>
>
> On Thu, Jan 8, 2026 at 9:32=E2=80=AFPM Fujii Masao <masao.fujii@gmail.com=
> wrote:
>>
>> On Thu, Jan 8, 2026 at 3:00=E2=80=AFAM Shruthi Gowda <gowdashru@gmail.co=
m> wrote:
>> >
>> >
>> > On Mon, Dec 8, 2025 at 9:39=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wr=
ote:
>> >>
>> >> 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 c=
heck on
>> >> > the connection handle before attempting to access it.
>> >>
>> >> Hmm ... poking around, I see several other places that aren't checkin=
g
>> >> the result of ecpg_get_connection.  Shouldn't we tighten them all?
>> >>
>> >>                         regards, tom lane
>> >
>> >
>> > I agree. I=E2=80=99ve reviewed all occurrences of ecpg_get_connection(=
) and noted that, in most instances, it is followed by ecpg_init(), which v=
alidates 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 =3D ecpg_get_connection(connection_name);
>> + if (!con)
>> + {
>> + ecpg_raise(lineno, ECPG_NO_CONN, ECPG_SQLSTATE_CONNECTION_DOES_NOT_EXI=
ST,
>> +    connection_name ? connection_name : ecpg_gettext("NULL"));
>>
>
>  Thanks for the feedback, Fujii. I agree=E2=80=94using ecpg_init() is a m=
ore consistent approach and aligns with how this is handled in other parts =
of the code.
> I have updated the patch to use ecpg_init() for validation. Please find t=
he 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=3DNULL for ECPGdeallocate_all,
ECPGprepared_statement and ECPGget_desc.

--=20
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com