BUG #16696: Backend crash in llvmjit - Mailing list pgsql-bugs
From | PG Bug reporting form |
---|---|
Subject | BUG #16696: Backend crash in llvmjit |
Date | |
Msg-id | 16696-29d944a33801fbfe@postgresql.org Whole thread Raw |
Responses |
Re: BUG #16696: Backend crash in llvmjit
|
List | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 16696 Logged by: Dmitry Marakasov Email address: amdmi3@amdmi3.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" }
pgsql-bugs by date: