Re: BUG #19609: Server crashes when executing a JIT-compiled SQL function on s390x

Hi, Tom and Artem!

I looked at this on qemu-system-s390x (TCG),
Ubuntu 24.04, with an unpatched PG JIT emitter.

Arch test
---------------

Same PG sources and JIT GUCs (jit=on, jit_above_cost=0,
jit_inline_above_cost=-1, …, jit_dump_bitcode=off):

s390x TCG, LLVM 16.0.6 / 18.1.3 / 19.1.1 — crash
("server closed the connection" on clean builds)
x86_64, LLVM 18.1.3 and 20.1.8 — OK (8/8; EXPLAIN shows
JIT Functions: 3, Inlining false)

So the failure is arch-specific in the sense Tom meant. Caveat:
my s390x crashes are under TCG, not a real Z box (the original
report was on hardware). qemu-user did not reproduce, full-system
TCG did.

Repro
-----

CREATE FUNCTION type_text(oid) RETURNS text
LANGUAGE sql STABLE
AS $$ SELECT typname::text FROM pg_catalog.pg_type
WHERE oid = $1 $$;

SELECT type_text(22) FROM generate_series(1,7) g;
-- TAP form with LIMIT 7 / count(*) fails the same way
-- generate_series(1,6) / LIMIT 6 is fine; jit=off and
-- allowing inlining are fine

With a diagnostic build, name_text sees a NULL byref Datum with
isnull=false on the 7th call. jit_dump_bitcode=on often hides
the bug.

Where it breaks (short)
-----------------------

Rough IR:

store i64 %d, ptr inttoptr (i64 <op->resvalue>)
call i64 @name_text(ptr inttoptr (i64 <fcinfo>))

Slot content on call #7 is still good (C read). Reloading
tts_values in IR does not help. A C helper that writes through
the resvalue pointer can make name_text see a good Datum. The IR
store via baked inttoptr does not. On call #7 I also saw live
ExprState/fcinfo addresses differ from earlier calls — so the
JIT is using a stronger "freeze absolute addresses at first
compile" contract than the interpreter.

I tried a tiny standalone clang test on the same s390x TCG guest
(store / store+call through compile-time inttoptr to a stable
heap cell, 8 times). That did *not* fail. So I do not yet have
a reduced LLVM testcase, a naive inttoptr store is not enough.

As an academic check only: if the JIT loads resvalue / resnull /
fcinfo from the live ExprState each step (IR GEP/load from
state->steps[opno]…) instead of baking them as l_ptr_const /
inttoptr, the repro stopped failing on my harness. I am not
proposing that as a patch — just a data point that the failure
is tied to the baked-address model on this target.

-------
Please treat QEMU TCG as a possible confounder
until someone confirms on real Z (original reporter: hardware,
LLVM 18.1.3).
I am filing this mainly as investigation notes. If any of it
helps with the LLVM report or with later PG work, good.

ср, 5 авг. 2026 г. в 19:15, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> =?UTF-8?B?0JDRgNGC0ZHQvCDQl9Cw0YDRg9Cx0LjQvQ==?= <a(dot)prototype7(at)gmail(dot)com>
> writes:
> > I am attaching the TAP test mentioned in the bug report.
>
> If the same test doesn't fail on other arches (x86, arm, etc) then
> this is almost certainly an LLVM bug, and you should be reporting
> it to them.
>
> regards, tom lane
>
>
>

--
Regards,
Rachitskiy Andrey