Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL - Mailing list pgsql-hackers

From Shruthi Gowda
Subject Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Date
Msg-id CAASxf_P5f=Frf8S7rN9BzphtCLoeN9vFuh-V7ukotOQZU54g+w@mail.gmail.com
Whole thread Raw
In response to Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
List pgsql-hackers

On Mon, Dec 8, 2025 at 9:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
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 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.
In a few cases, the caller had already validated the connection. However, I identified an additional case that lacked this check, so I have revised the patch to include the missing validation.


Thanks & Regards,

Shruthi K C

EnterpriseDBhttp://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Fix comments on _bt_skiparray_strat_increment/decrement
Next
From: Jim Mlodgenski
Date:
Subject: Re: Support allocating memory for large strings