Обсуждение: psql crash with custom build on RedHat 7

On Wed, Dec 20, 2023 at 1:39 AM Dominique Devienne <ddevienne@gmail.com> wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004232b8 in slash_yylex ()

I think this might have to do with flex changing.  Does it help if you
"make maintainer-clean"?

Thomas Munro <thomas.munro@gmail.com> writes:
> On Wed, Dec 20, 2023 at 1:39 AM Dominique Devienne <ddevienne@gmail.com> wrote:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00000000004232b8 in slash_yylex ()

> I think this might have to do with flex changing.  Does it help if you
> "make maintainer-clean"?

If that doesn't fix it, please build with --enable-debug so that you
can get a more detailed stack trace.

            regards, tom lane

On Wed, Dec 20, 2023 at 4:41 AM Dominique Devienne <ddevienne@gmail.com> wrote:
> On Tue, Dec 19, 2023 at 2:02 PM Thomas Munro <thomas.munro@gmail.com> wrote:
>> On Wed, Dec 20, 2023 at 1:39 AM Dominique Devienne <ddevienne@gmail.com> wrote:
>> > Program received signal SIGSEGV, Segmentation fault.
>> > 0x00000000004232b8 in slash_yylex ()
>>
>> I think this might have to do with flex changing.  Does it help if you
>> "make maintainer-clean"?
>
> My colleague who did the custom build double-checked the flex/bison requirements,
> and the version of the packages on the RH7 machine he built on, and they check out (see below).
>
> He also tells me he builds debug and release versions off different workspaces/checkouts,
> thus there are no remnants of previous builds, assuming that's what `make maintainer-clean` is for.

OK but be warned that if you're using tarballs, we shipped lexer
remnants in the tree (until
https://github.com/postgres/postgres/commit/721856ff, an interesting
commit to read).  The slash lexer is a kind of extension that (IIRC)
shares the same PsqlScanState (opaque pointer to private lexer state),
but if these two things are compiled to C by different flex versions,
they may contain non-identical 'struct yyguts_t' (and even if the
structs were identical, what the code does with them might still be
incompatible, but I guess the struct itself would be a good first
thing to look at along with the versions mentioned near the top of the
.c):

src/fe_utils/psqlscan.l -> psqlscan.c
src/bin/psql/psqlscanslash.l -> psqlscanslash.c

The usual "clean" doesn't remove those .c files in PG < 17, which
means that if your pipeline involves tarballs but you finished up
regenerating one of the files, or some other sequence involving
different flex versions, you could get that.  I've seen it myself on a
few systems, a decade ago when I guess flex rolled out an incompatible
change (maybe contemporaneous with RHEL7) and flex was upgraded
underneath my feet.  I remember that "maintainer-clean" (or maybe I'm
misremembering and it was "distclean") fixed it.