Re: Segmentation Fault PG 14

From: Jeffrey Walton <noloader(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Segmentation Fault PG 14
Date: 2022-11-07 23:47:24
Message-ID: CAH8yC8=aRUGEL8pBua2cQz_QUfvsaEuKro_XX6QPtn7Q9dFZqw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Nov 7, 2022 at 2:38 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Willian Colognesi <willian_colognesi(at)trimble(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jan Bilek 2022-11-08 01:24:49 PCI:SSF - Safe SQL Query & operators filter
Previous Message Tom Lane 2022-11-07 23:05:04 Re: Segmentation Fault PG 14