Re: Segmentation Fault PG 14 - Mailing list pgsql-general

From Jeffrey Walton
Subject Re: Segmentation Fault PG 14
Date
Msg-id CAH8yC8=aRUGEL8pBua2cQz_QUfvsaEuKro_XX6QPtn7Q9dFZqw@mail.gmail.com
Whole thread Raw
In response to Re: Segmentation Fault PG 14  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Mon, Nov 7, 2022 at 2:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Willian Colognesi <willian_colognesi@trimble.com> writes:
> > `I take it things were okay with the version you used previously?`
>
> > Yes, it was working pretty well in another instance with pg version
> > `12.4-1.pgdg18.04+1`, and we had to make a migration of one database that
> > was running in this server to another using Logical Replication.
>
> 12.4 to 14.5 is kind of a big jump :-(.
>
> The stack trace seems to indicate that ExecProcNode transferred control
> to never-never land, which says that something clobbered the function
> pointer it's trying to indirect through.  I don't recall having seen
> any similar reports though.

I'm just thinking out loud... I've seen the latest GCC do that on what
it believes to be dead code. Our problem was detailed at
https://github.com/weidai11/cryptopp/issues/1141 .

We identified the problem by building/running our self tests with
-fsanitize=unreachable .

Testing with -fsanitize=unreachable should confirm or rule out GCC and
Clang [incorrectly] removing code that is actually needed. If this is
the problem, then -fsanitize=unreachable will also provide a usable
stack trace and provide a useful debugging experience.

Jeff



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Segmentation Fault PG 14
Next
From: Jan Bilek
Date:
Subject: PCI:SSF - Safe SQL Query & operators filter