Re: Failed assertion with jit enabled - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Failed assertion with jit enabled
Date
Msg-id Z6OgkTI6l0hCYaf5@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Failed assertion with jit enabled  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Failed assertion with jit enabled
Re: Failed assertion with jit enabled
List pgsql-hackers
Hi,

On Wed, Feb 05, 2025 at 10:51:17AM -0500, Tom Lane wrote:
> Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
> > I was doing some tests and managed to trigger a failed assertion with jit
> > enabled.
> 
> > The test can be simplified to:
> 
> > postgres=# select count(*) from generate_series(1,10000000);
> > server closed the connection unexpectedly
> 
> Hmm, works for me on today's HEAD.

Thanks for looking at it!

> > The failed assertion is:
> > TRAP: failed Assert("false"), File: "llvmjit_expr.c", Line: 2833, PID: 3060333
> 
> There are two Assert(false) in that file, neither of them particularly
> close to line 2833 as of today, so I'm not sure what version you are
> using or which one you're hitting.  Nonetheless, I'll go out on a
> limb and guess that this will go away if you do "git clean -dfxq"
> and a full rebuild.

Yeah that's my default way to do and that was done that way.

> It smells like different files getting out of
> sync about the representation of ExprEvalOp or ExprEvalStep.
> 

I did look more closely (knowing that it works for you) and the issue is linked
to not using --with-llvm. Inded, I used to use --with-llvm but removed it some
time ago for testing.

So the failed build was not using --with-llvm and was relying on an old version
of llvmjit.so (build from the last time I used --with-llvm)...

As a default I also always use "maintainer-clean" but it looks like it does not
remove llvmjit.so from the installation directory: is that a miss?

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)
Next
From: Ranier Vilela
Date:
Subject: Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)