JIT crash introduced by 6185c9737c with LLVM 14

Started by Jeff Davisalmost 2 years ago8 messagesbugs
Jump to latest
#1Jeff Davis
jeff@j-davis.com

The following query causes a crash on an optimized build using LLVM 14:

create table t(i int);
set jit_above_cost=0;
select count(*) from t;

I bisected the crash to 6185c9737c.

Regards,
Jeff Davis

#2Amit Langote
Langote_Amit_f8@lab.ntt.co.jp
In reply to: Jeff Davis (#1)
Re: JIT crash introduced by 6185c9737c with LLVM 14

Hi Jeff,

On Fri, Jun 14, 2024 at 1:25 PM Jeff Davis <jeff@j-davis.com> wrot>

The following query causes a crash on an optimized build using LLVM 14:

create table t(i int);
set jit_above_cost=0;
select count(*) from t;

I bisected the crash to 6185c9737c.

Thanks for the report. Will look into it.

--
Thanks, Amit Langote

#3Amit Langote
Langote_Amit_f8@lab.ntt.co.jp
In reply to: Amit Langote (#2)
Re: JIT crash introduced by 6185c9737c with LLVM 14

Hi Jeff,

On Fri, Jun 14, 2024 at 2:57 PM Amit Langote <amitlangote09@gmail.com> wrote:

On Fri, Jun 14, 2024 at 1:25 PM Jeff Davis <jeff@j-davis.com> wrot>

The following query causes a crash on an optimized build using LLVM 14:

create table t(i int);
set jit_above_cost=0;
select count(*) from t;

I bisected the crash to 6185c9737c.

Thanks for the report. Will look into it.

Would you please share more details about the crash (llvm build
attributes, etc.) as I'm unable to reproduce this crash with
libLLVM-14.so that I built from sources that I got at [1]https://github.com/llvm/llvm-project/releases/tag/llvmorg-14.0.6. No luck
even after building with -DLLVM_ENABLE_ASSERTIONS=ON. I'm building PG
HEAD with --buildtype=release.

--
Thanks, Amit Langote

[1]: https://github.com/llvm/llvm-project/releases/tag/llvmorg-14.0.6

#4Amit Langote
Langote_Amit_f8@lab.ntt.co.jp
In reply to: Amit Langote (#3)
Re: JIT crash introduced by 6185c9737c with LLVM 14

Hi,

On Mon, Jun 17, 2024 at 6:32 PM Amit Langote <amitlangote09@gmail.com> wrote:

Hi Jeff,

On Fri, Jun 14, 2024 at 2:57 PM Amit Langote <amitlangote09@gmail.com> wrote:

On Fri, Jun 14, 2024 at 1:25 PM Jeff Davis <jeff@j-davis.com> wrot>

The following query causes a crash on an optimized build using LLVM 14:

create table t(i int);
set jit_above_cost=0;
select count(*) from t;

I bisected the crash to 6185c9737c.

Thanks for the report. Will look into it.

Would you please share more details about the crash (llvm build
attributes, etc.) as I'm unable to reproduce this crash with
libLLVM-14.so that I built from sources that I got at [1]. No luck
even after building with -DLLVM_ENABLE_ASSERTIONS=ON. I'm building PG
HEAD with --buildtype=release.

Also, could you please check if the crash still occurs after applying
the attached patch which removes the changes that 6185c9737c made to
files under src/backend/jit?

(My colleague David Rowley offered to test it on a raspberrypi and on
a x86_64 machine with libLLVM-14.so, but sees no crash using those
steps.)

--
Thanks, Amit Langote

Attachments:

v1-0001-SQL-JSON-Remove-src-backend-jit-changes-for-testi.patchapplication/octet-stream; name=v1-0001-SQL-JSON-Remove-src-backend-jit-changes-for-testi.patchDownload+0-112
#5Jeff Davis
pgsql@j-davis.com
In reply to: Amit Langote (#4)
Re: JIT crash introduced by 6185c9737c with LLVM 14

On Tue, 2024-06-18 at 15:11 +0900, Amit Langote wrote:

Also, could you please check if the crash still occurs after applying
the attached patch which removes the changes that 6185c9737c made to
files under src/backend/jit?

(My colleague David Rowley offered to test it on a raspberrypi and on
a x86_64 machine with libLLVM-14.so, but sees no crash using those
steps.)

My testcase was wrong because I was installing into the same
destination directory each time when bisecting (that shortcut normally
works but can cause problems with LLVM changes). When I install into a
fresh directory, it works.

There may (or may not) have been some bug in my original larger case,
but I'll have to re-investigate, and in any case I don't think your
commit was a problem.

Regards,
Jeff Davis

#6Thomas Munro
thomas.munro@gmail.com
In reply to: Jeff Davis (#5)
Re: JIT crash introduced by 6185c9737c with LLVM 14

On Wed, Jun 19, 2024 at 3:20 AM Jeff Davis <pgsql@j-davis.com> wrote:

There may (or may not) have been some bug in my original larger case,
but I'll have to re-investigate, and in any case I don't think your
commit was a problem.

There are some unresolved reports of crashes on ARM CPUs using LLVM 14
in particular. What is your CPU?

#7Michael Paquier
michael@paquier.xyz
In reply to: Thomas Munro (#6)
Re: JIT crash introduced by 6185c9737c with LLVM 14

On Wed, Jun 19, 2024 at 11:03:11AM +1200, Thomas Munro wrote:

On Wed, Jun 19, 2024 at 3:20 AM Jeff Davis <pgsql@j-davis.com> wrote:

There may (or may not) have been some bug in my original larger case,
but I'll have to re-investigate, and in any case I don't think your
commit was a problem.

Okay, for now I have removed Amit's name as owner of this open item.

There are some unresolved reports of crashes on ARM CPUs using LLVM 14
in particular. What is your CPU?

But it looks like we still have something new to v17 in this case, so
the item it still around, pending more investigation.
--
Michael

#8Amit Langote
Langote_Amit_f8@lab.ntt.co.jp
In reply to: Michael Paquier (#7)
Re: JIT crash introduced by 6185c9737c with LLVM 14

On Wed, Jun 19, 2024 at 8:52 AM Michael Paquier <michael@paquier.xyz> wrote:

On Wed, Jun 19, 2024 at 11:03:11AM +1200, Thomas Munro wrote:

On Wed, Jun 19, 2024 at 3:20 AM Jeff Davis <pgsql@j-davis.com> wrote:

There may (or may not) have been some bug in my original larger case,
but I'll have to re-investigate, and in any case I don't think your
commit was a problem.

Ok, thanks.

Okay, for now I have removed Amit's name as owner of this open item.

There are some unresolved reports of crashes on ARM CPUs using LLVM 14
in particular. What is your CPU?

But it looks like we still have something new to v17 in this case, so
the item it still around, pending more investigation.

+1. I was about to mark it as resolved, but this makes sense.

--
Thanks, Amit Langote