pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: PG Bug reporting form <noreply@postgresql.org>
To: pgsql-bugs@lists.postgresql.org
Cc: amdmi3@amdmi3.ru
Subject: BUG #16696: Backend crash in llvmjit
Date: Mon, 02 Nov 2020 21:47:17 +0000
Message-ID: <16696-29d944a33801fbfe@postgresql.org> (raw)

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"
}



view thread (14+ messages)  latest in thread

Message-ID: <16696-29d944a33801fbfe@postgresql.org>
Permalink:  ../16696-29d944a33801fbfe@postgresql.org/
Also on:    postgresql.org/message-id/16696-29d944a33801fbfe@postgresql.org

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: noreply@postgresql.org, pgsql-bugs@lists.postgresql.org, amdmi3@amdmi3.ru
  Subject: Re: BUG #16696: Backend crash in llvmjit
  In-Reply-To: <16696-29d944a33801fbfe@postgresql.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox