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

On Thu, Jan 8, 2026 at 9:32 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Thu, Jan 8, 2026 at 3:00 AM Shruthi Gowda <gowdashru(at)gmail(dot)com> wrote:
> >
> >
> > On Mon, Dec 8, 2025 at 9:39 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >>
> >> Shruthi Gowda <gowdashru(at)gmail(dot)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"));
>
>
Thanks for the feedback, Fujii. I agree—using ecpg_init() is a more
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 the
revised version attached.
The patch works for MASTER and all the back branches.

Thanks & Regards,

Shruthi K C

EnterpriseDB: http://www.enterprisedb.com