BUG #16696: Backend crash in llvmjit

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: amdmi3(at)amdmi3(dot)ru
Subject: BUG #16696: Backend crash in llvmjit
Date: 2020-11-02 21:47:17
Message-ID: 16696-29d944a33801fbfe@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 16696
Logged by: Dmitry Marakasov
Email address: amdmi3(at)amdmi3(dot)ru
PostgreSQL version: 13.0
Operating system: FreeBSD 12.1
Description:

Hi!

I've ran into llvmjit related backend crash with a query involving unnesting
a column which contains array of arrays in jsonb format. I've been able to
isolate a query which triggers the problem:

BEGIN;
CREATE TEMP TABLE test AS
SELECT
(
SELECT
jsonb_agg('["foofoofoo","foofoofoo","*","*","*","*","*","*","*","*",true,false]'::jsonb)
FROM generate_series(1,1000)
) AS data
FROM generate_series(1, 10000);

SELECT COUNT(*) FROM(
SELECT
jsonb_array_elements(data)->>0,
jsonb_array_elements(data)->>1,
jsonb_array_elements(data)->>2,
jsonb_array_elements(data)->>3,
jsonb_array_elements(data)->>4,
jsonb_array_elements(data)->>5,
jsonb_array_elements(data)->>6,
jsonb_array_elements(data)->>7,
jsonb_array_elements(data)->>8,
jsonb_array_elements(data)->>9,
(jsonb_array_elements(data)->>10)::boolean,
(jsonb_array_elements(data)->>11)::boolean
FROM test
) AS t;
ROLLBACK;

The result is 100% reproduciby on my setup:

% psql < test.sql
BEGIN
SELECT 10000
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
connection to server was lost

Syslog: "pid 53852 (postgres), jid 0, uid 770: exited on signal 11 (core
dumped)"

Expected result which is achievable on PostgreSQL compiled without LLVM
support:

% psql < test.sql
BEGIN
SELECT 10000
count
----------
10000000
(1 row)

ROLLBACK

Environment details:
- FreeBSD 12.1 amd64
- PostgreSQL 13.0 (built from FreeBSD ports)
- llvm-10.0.1 (build from FreeBSD ports)
- version(): PostgreSQL 13.0 on amd64-portbld-freebsd12.1, compiled by
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM
8.0.1), 64-bit
- the config is as far as I can tell default: http://dpaste.com//AJ4RCJ7DG

Note that the problem may be related to some buffer overflow, as using less
rows in test table or less nested arrays in the jsonb field makes the
problem go away.

Backtrace:

(lldb) bt
* thread #1, name = 'postgres', stop reason = signal SIGSEGV
* frame #0: 0x0000000810f4a70b
frame #1: 0x000000080bfded8d
llvmjit.so`ExecRunCompiledExpr(state=0x000000080b18a850,
econtext=0x0000000801bc2a80, isNull=0x00007fffffffddd7) at
llvmjit_expr.c:2424:9
frame #2: 0x00000000007dd70b
postgres`ExecEvalExprSwitchContext(state=0x000000080b18a850,
econtext=0x0000000801bc2a80, isNull=0x00007fffffffddd7) at
executor.h:313:13
frame #3: 0x00000000007dd669
postgres`ExecProject(projInfo=0x000000080b18a848) at executor.h:347:9
frame #4: 0x00000000007dd42f
postgres`ExecResult(pstate=0x0000000801bc2970) at nodeResult.c:136:10
frame #5: 0x00000000007a1035
postgres`ExecProcNodeFirst(node=0x0000000801bc2970) at
execProcnode.c:450:9
frame #6: 0x00000000007b5e22
postgres`ExecProcNode(node=0x0000000801bc2970) at executor.h:245:9
frame #7: 0x00000000007b5a4c
postgres`fetch_input_tuple(aggstate=0x0000000801bc2398) at
nodeAgg.c:589:10
frame #8: 0x00000000007b5678
postgres`agg_retrieve_direct(aggstate=0x0000000801bc2398) at
nodeAgg.c:2356:17
frame #9: 0x00000000007b250e postgres`ExecAgg(pstate=0x0000000801bc2398)
at nodeAgg.c:2171:14
frame #10: 0x00000000007a1035
postgres`ExecProcNodeFirst(node=0x0000000801bc2398) at
execProcnode.c:450:9
frame #11: 0x0000000000799db2
postgres`ExecProcNode(node=0x0000000801bc2398) at executor.h:245:9
frame #12: 0x0000000000796161
postgres`ExecutePlan(estate=0x0000000801bc2118,
planstate=0x0000000801bc2398, use_parallel_mode=false, operation=CMD_SELECT,
sendTuples=true, numberTuples=0, direction=ForwardScanDirection,
dest=0x000000080b565f00, execute_once=true) at execMain.c:1646:10
frame #13: 0x000000000079602e
postgres`standard_ExecutorRun(queryDesc=0x000000080220e918,
direction=ForwardScanDirection, count=0, execute_once=true) at
execMain.c:364:3
frame #14: 0x0000000000795e84
postgres`ExecutorRun(queryDesc=0x000000080220e918,
direction=ForwardScanDirection, count=0, execute_once=true) at
execMain.c:308:3
frame #15: 0x00000000009f4928
postgres`PortalRunSelect(portal=0x000000080b0c3118, forward=true, count=0,
dest=0x000000080b565f00) at pquery.c:912:4
frame #16: 0x00000000009f438d
postgres`PortalRun(portal=0x000000080b0c3118, count=9223372036854775807,
isTopLevel=true, run_once=true, dest=0x000000080b565f00,
altdest=0x000000080b565f00, qc=0x00007fffffffe3a0) at pquery.c:756:18
frame #17: 0x00000000009efc10
postgres`exec_simple_query(query_string="SELECT COUNT(*)
FROM(\n\t\tSELECT\n\t\t\tjsonb_array_elements(data)->>0,\n\t\t\tjsonb_array_elements(data)->>1,\n\t\t\tjsonb_array_elements(data)->>2,\n\t\t\tjsonb_array_elements(data)->>3,\n\t\t\tjsonb_array_elements(data)->>4,\n\t\t\tjsonb_array_elements(data)->>5,\n\t\t\tjsonb_array_elements(data)->>6,\n\t\t\tjsonb_array_elements(data)->>7,\n\t\t\tjsonb_array_elements(data)->>8,\n\t\t\tjsonb_array_elements(data)->>9,\n\t\t\t(jsonb_array_elements(data)->>10)::boolean,\n\t\t\t(jsonb_array_elements(data)->>11)::boolean\n\t\tFROM
test\n\t) AS t;") at postgres.c:1239:10
frame #18: 0x00000000009eeec9 postgres`PostgresMain(argc=1,
argv=0x000000080b0ac730, dbname="repology", username="repology") at
postgres.c:4315:7
frame #19: 0x000000000092bcb7
postgres`BackendRun(port=0x000000080b0a5000) at postmaster.c:4536:2
frame #20: 0x000000000092b090
postgres`BackendStartup(port=0x000000080b0a5000) at postmaster.c:4220:3
frame #21: 0x000000000092a073 postgres`ServerLoop at
postmaster.c:1739:7
frame #22: 0x0000000000927d52 postgres`PostmasterMain(argc=3,
argv=0x00007fffffffeb48) at postmaster.c:1412:11
frame #23: 0x0000000000819bcf postgres`main(argc=3,
argv=0x00007fffffffeb48) at main.c:210:3
frame #24: 0x00000000004cb10f postgres`_start(ap=<unavailable>,
cleanup=<unavailable>) at crt1.c:76:7

Some locals at #1

(lldb) print *state
(ExprState) $6 = {
tag = T_ExprState
flags = '\0'
resnull = false
resvalue = 34388814424
resultslot = 0x0000000801bc3ec0
steps = 0x000000080b4a7f38
evalfunc = 0x0000000810f4a120
expr = 0x000000080b564940
evalfunc_private = 0x000000080b4a9fe0
steps_len = 39
steps_alloc = 64
parent = 0x0000000801bc2970
ext_params = 0x0000000000000000
innermost_caseval = 0x0000000000000000
innermost_casenull = 0x0000000000000000
innermost_domainval = 0x0000000000000000
innermost_domainnull = 0x0000000000000000
}
(lldb) print *econtext
(ExprContext) $7 = {
type = T_ExprContext
ecxt_scantuple = 0x0000000000000000
ecxt_innertuple = 0x0000000000000000
ecxt_outertuple = 0x0000000801bc31e0
ecxt_per_query_memory = 0x0000000801bc2000
ecxt_per_tuple_memory = 0x0000000801bba000
ecxt_param_exec_vals = 0x0000000000000000
ecxt_param_list_info = 0x0000000000000000
ecxt_aggvalues = 0x0000000000000000
ecxt_aggnulls = 0x0000000000000000
caseValue_datum = 0
caseValue_isNull = true
domainValue_datum = 0
domainValue_isNull = true
ecxt_estate = 0x0000000801bc2118
ecxt_callbacks = 0x0000000000000000
}
(lldb) print *isNull
(bool) $8 = false
(lldb) print *(CompiledExprState*)state->evalfunc_private
(CompiledExprState) $16 = {
context = 0x000000080b126050
funcname = 0x000000080b4a90d8 "evalexpr_0_2"
}

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-11-02 22:15:02 Re: BUG #16695: pg_hba_file_rules NULL address and netmask
Previous Message Dmitry Marakasov 2020-11-02 21:45:09 Re: BUG #16696: Backend crash in llvmjit