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

Поиск
Список
Период
Сортировка
От Shruthi Gowda
Тема Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Дата
Msg-id CAASxf_P5f=Frf8S7rN9BzphtCLoeN9vFuh-V7ukotOQZU54g+w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL
Список 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

Вложения

В списке pgsql-hackers по дате отправления: