Re: BUG #19612: SEGV in ParseConfigFp() in guc-file.l

From: Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: ilia(dot)kashintsev(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19612: SEGV in ParseConfigFp() in guc-file.l
Date: 2026-08-16 06:50:26
Message-ID: CAB8bMitea+w7igvgag4wVa5wS-Zh5HVONJK0AKELxdgxFSM5JQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

вс, 16 авг. 2026 г. в 11:05, Michael Paquier <michael(at)paquier(dot)xyz>:

> I don't follow this argument. ParseConfigFp(), ParseConfigFile() or
> ProcessConfigFile() can be called with an elevel lower than ERROR, and
> we have quite a few callers that do so.
>
> Sorry, that argument was too narrow. I was only looking at the
longjmp from a flex fatal, where the scanner is already live.

It seems to me that we should also have a `goto cleanup` if
> yylex_init() fails, also pointing at d663f150b5ed that has switched
> the scanner to be reentrant where yylex_init() has been added.
>
> Agreed.
One gap in the snippet: OK is still true on that path, so we would
report a successful parse. That should be:
```
if (yylex_init(&scanner_init) != 0)
{
elog(elevel, "yylex_init() failed: %m");
OK = false;
goto cleanup;
}
```
With that, I am fine taking your version.

--
Regards,
Rachitskiy Andrey

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Rachitskiy 2026-08-16 14:29:25 Re: BUG #19621: Unexpected results of JSON_VALUE with DEFAULT ON EMPTY
Previous Message Michael Paquier 2026-08-16 06:05:13 Re: BUG #19612: SEGV in ParseConfigFp() in guc-file.l