Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: BUG #19609: Server crashes when executing a JIT-compiled SQL function
 on s390x
To: pgsql-bugs@lists.postgresql.org
From: PG Bug reporting form <noreply@postgresql.org>
Cc: a.prototype7@gmail.com
Reply-To: a.prototype7@gmail.com, pgsql-bugs@lists.postgresql.org
Date: Tue, 04 Aug 2026 12:27:18 +0000
Message-ID: <19609-e5278efcee2b4419@postgresql.org>
Auto-Submitted: auto-generated
Archived-At: 
 <https://www.postgresql.org/message-id/19609-e5278efcee2b4419%40postgresql.org>
Precedence: bulk

The following bug has been logged on the website:

Bug reference:      19609
Logged by:          Artem Zarubin
Email address:      a.prototype7@gmail.com
PostgreSQL version: 19beta2
Operating system:   Ubuntu 24.04.4 LTS (s390x)
Description:       =20

Hello, I found a reproducible server crash when an SQL-language function is
executed with LLVM JIT enabled on s390x.

Tested commit:

  bad: 0392fb900eb89f52988cccd33046443c39c70d1c, PostgreSQL 19devel

The server was built with:

  ./configure \
    --prefix=3D/home/test/pginstall-vanilla18 \
    --enable-debug \
    --enable-cassert \
    --with-llvm \
    LLVM_CONFIG=3D/usr/bin/llvm-config-18 \
    CLANG=3D/usr/bin/clang-18

Environment:

  Architecture: s390x
  OS: Ubuntu 24.04.4 LTS
  Kernel: Linux 6.8.0-136-generic
  GCC: 13.3.0
  LLVM: 18.1.3

The following parameters are used by the attached TAP test:

  restart_after_crash =3D on
  jit =3D on

Minimal SQL script to reproduce:

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

  SET jit =3D on;
  SET jit_above_cost =3D 0;
  SET jit_inline_above_cost =3D -1;
  SET jit_optimize_above_cost =3D -1;
  SET jit_expressions =3D on;
  SET jit_tuple_deforming =3D off;

  SELECT count(*)
  FROM (
    SELECT oid
    FROM pg_catalog.pg_type
    ORDER BY oid
    LIMIT 7
  ) AS t
  WHERE type_text(t.oid) =3D 'int2vector';

Expected result:

  count
  -------
      1
  (1 row)

Actual result:

  server closed the connection unexpectedly
  This probably means the server terminated abnormally before or while
processing the request.
  connection to server was lost

The server log contains:

  LOG: client backend (PID ...) was terminated by signal 11: Segmentation
fault
  DETAIL: Failed process was running: SELECT count(*) ...

Complete backtrace available from the core dump produced by the minimal
reproducer:

  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  0x000002aa3d0f29bc in cstring_to_text (s=3D0x0) at varlena.c:186
  #1  name_text (fcinfo=3D<optimized out>) at varlena.c:2709
  #2  0x000003ff9ae36126 in ?? ()
  Backtrace stopped: frame did not save the PC

  si_signo =3D 11 (SIGSEGV)
  si_code =3D 1 (SEGV_MAPERR)
  si_addr =3D 0x0

  r1  =3D 0x0
  r11 =3D 0x0
  pc  =3D 0x2aa3d0f29bc <name_text+60>

The frame above name_text() contains JIT-generated code without unwind
information.  name_text() receives a NULL C-string pointer and crashes in
cstring_to_text().

With jit=3Doff, the same query completes successfully and returns 1.  LLVM
inlining and PostgreSQL's expensive-query JIT optimization tier are not
required: the crash is also reproduced with jit_inline_above_cost and
jit_optimize_above_cost set to -1.

The attached patch adds the reproducer as
src/test/modules/test_misc/t/014_jit_s390x.pl.  From the PostgreSQL source
tree, I ran it against the installed build with:

  PG_INSTALL=3D/home/test/pginstall-vanilla18
  PATH=3D"$PG_INSTALL/bin:$PATH" \
  PERL5LIB=3D"$PWD/src/test/perl" \
  PG_REGRESS=3D"$PWD/src/test/regress/pg_regress" \
  prove -v src/test/modules/test_misc/t/014_jit_s390x.pl

The TAP test fails as follows because the backend crashes:

  not ok 1 - JIT-compiled SQL function expression does not crash the backend
  got: '2'
  expected: '0'
  not ok 2 - JIT-compiled SQL function expression returns expected row
  got: ''
  expected: '1'

The crash reproduced on every run of the final minimal test on this machine,
including runs against newly initialized test clusters.

---
Best regards,
Artem Zarubin
Postgres Professional: https://postgrespro.com/