Re: BUG #16696: Backend crash in llvmjit

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Palle <girgen(at)pingpong(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #16696: Backend crash in llvmjit
Date: 2021-07-18 05:13:50
Message-ID: CA+hUKG+LaEwA0KwDgAjsuKy2yT+q2coNVh2hFfdQxsgAA-C+zA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, May 20, 2021 at 2:49 AM Palle <girgen(at)pingpong(dot)net> wrote:
> This seems to still not be fixed. Is it planned for 14.0 release?

I don't know enough about LLVM and TLS to have an opinion on the
details, but I tested this and it works, and I think it should
probably be back-patched based on the discussion so far (and hopefully
in the future some way can be figured out to make it actually work?).

When I tested the original repro, I got SIGTRAP (not SIGSEGV as
reported) with LLVM 9 and 10, while 11, 12 and 13 failed gracefully
with:

2021-07-18 15:27:42.785 NZST [78884] FATAL: fatal llvm error:
Relocation type not implemented yet!

I was reminded of this thread because I happened to see a
relevant-looking commit whiz past in the FreeBSD commit log[1]: libc
is changing to a different TLS model. I just tried that, and it makes
no difference.

In case it helps someone who wants to see this failure, I recently
XKCD1319'd myself into producing Vagrant files for PostgreSQL hacking
on various OSes[2] after a clash with illumos on the build farm (cd
freebsd12; vagrant up; vagrant ssh; you'll find a fresh build of the
PostgreSQL master branch built against LLVM 9 under ~/install).

[1] https://cgit.freebsd.org/src/commit/?id=9c97062b620137a1f7cad4c6b3fb030a396b3266
[2] https://github.com/macdice/postgresql-dev-vagrant/

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Borodin 2021-07-18 05:17:28 Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Previous Message Peter Geoghegan 2021-07-18 01:24:42 Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows