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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com>, 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 22:26:26
Message-ID: aoI5El4tC-uBbU2c@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sun, Aug 16, 2026 at 10:32:14AM -0400, Tom Lane wrote:
> Michael Paquier <michael(at)paquier(dot)xyz> writes:
> > 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.
>
> Yeah. The other thing not being covered here is the possibility
> that yy_create_buffer fails and returns NULL.

Are you worried about possible future changes on the flex side? If I
read src/c99-flex.skl in the flex repo, yy_create_buffer() always uses
yypanic(), which would trigger the sigjmp. yylex_init() just sets an
ENOMEM and returns NULL.

Saying that, I can see your point in making our code more defensive,
on the assumption that upstream could change things, or based on the
assumption that we would catch failures if the error handling in
guc-file.l is touched one way or another.
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Zexin Li 2026-08-16 23:36:01 Re: BUG #19583: macaddr input accepts octet fields longer than 8 hex digits
Previous Message Andrey Borodin 2026-08-16 16:01:18 Re: BUG #19620: pg_class index corruption caused by statement_timeout during VACUUM FULL