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
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 |