BUG #17620: JIT-Compiler causes Segmentation Fault
The following bug has been logged on the website:
Bug reference: 17620
Logged by: Marcel Spitz
Email address: marcel.spitz@envelio.de
PostgreSQL version: 13.8
Operating system: Debian GNU/Linux 11 (bullseye) on linux/arm64
Description:
This can be reproduced with the official Docker Image "postgres:13.8".
Steps to reproduce:
First install the Debian Package `postgresql-13-postgis-3`
Set the value of shared_buffers to be above "1967636kB" (shared_buffers =
2GB will do)
Execute the following script:
```
SET jit_above_cost = 1;
CREATE TABLE IF NOT EXISTS t1 (
int_id BIGINT primary key,
text_id varchar
);
CREATE UNIQUE INDEX index_1 ON t1 (text_id);
CREATE TABLE IF NOT EXISTS t2
(
ext_id bigint,
text_id varchar,
int_id bigint,
a bigint,
b bigint,
c bigint,
d bigint,
e bigint,
f bigint
);
INSERT INTO t2 (ext_id, text_id) VALUES (0,0);
CREATE INDEX index_2 on t2 (text_id);
UPDATE t2 SET int_id = t1.int_id FROM t1 WHERE t2.text_id = t1.text_id;
```
With the Update Statement a Segmentation Fault occurs and this is what shows
in the logs (with DEBUG5)
```
[43]: DEBUG: time to inline: 0.000s, opt: 0.000s, emit: 0.003s psql:/files/test.sql:32: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. psql:/files/test.sql:32: fatal: connection to server was lost
INPROGRESS, xid/subid/cid: 0/1/0
[43]: DEBUG: time to inline: 0.000s, opt: 0.000s, emit: 0.003s psql:/files/test.sql:32: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. psql:/files/test.sql:32: fatal: connection to server was lost
psql:/files/test.sql:32: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
psql:/files/test.sql:32: fatal: connection to server was lost
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
Segmentation fault
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
FROM t1 WHERE t2.text_id = t1.text_id;
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
fault
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
FROM t1 WHERE t2.text_id = t1.text_id;
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
[39]: DEBUG: proc_exit(-1): 0 callbacks to make
[39]: DEBUG: proc_exit(-1): 0 callbacks to make
[39]: DEBUG: proc_exit(-1): 0 callbacks to make
[38]: HINT: In a moment you should be able to reconnect to the database and repeat your command.
process
[38]: HINT: In a moment you should be able to reconnect to the database and repeat your command.
the current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
[38]: HINT: In a moment you should be able to reconnect to the database and repeat your command.
repeat your command.
[39]: DEBUG: proc_exit(-1): 0 callbacks to make
[39]: DEBUG: proc_exit(-1): 0 callbacks to make
[39]: DEBUG: proc_exit(-1): 0 callbacks to make
[39]: DEBUG: proc_exit(-1): 0 callbacks to make
[39]: DEBUG: proc_exit(-1): 0 callbacks to make
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
[33]: DEBUG: cleaning up dynamic shared memory control segment with ID 209425142 ```
209425142
```
A core dump is produced as well, but it is not of any use, i presume because
of JIT Compilation
Hi,
On 2022-09-22 15:52:07 +0000, PG Bug reporting form wrote:
This can be reproduced with the official Docker Image "postgres:13.8".
Steps to reproduce:
First install the Debian Package `postgresql-13-postgis-3`
Hm - is that part required to trigger the problem? Your reproducer doesn't
reference postgis anywhere....
I tried to reproduce this, without success, neither inside nor outside a
container. I did start the container with podman, not docker though.
A core dump is produced as well, but it is not of any use, i presume because
of JIT Compilation
Does the core dump look more sensible if you turn on 'jit_debugging_support'?
Greetings,
Andres Freund