v16dev: invalid memory alloc request size 8488348128

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>
Subject: v16dev: invalid memory alloc request size 8488348128
Date: 2023-04-14 20:36:30
Message-ID: ZDm5TuKsh3tzoEjz@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I hit this elog() while testing reports under v16 and changed to PANIC
to help diagnose.

DETAILS: PANIC: invalid memory alloc request size 18446744072967930808
CONTEXT: PL/pgSQL function array_weight(real[],real[]) while storing call arguments into local variables

I can't share the query, data, nor plpgsql functions themselves.

I reproduced the problem at this commit, but not at its parent.

commit 42b746d4c982257bf3f924176632b04dc288174b (HEAD)
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Thu Oct 6 13:27:34 2022 -0400

Remove uses of MemoryContextContains in nodeAgg.c and
nodeWindowAgg.c.

#2 0x0000000001067af5 in errfinish (filename=filename(at)entry=0x168f1e0 "../src/backend/utils/mmgr/mcxt.c", lineno=lineno(at)entry=1013,
funcname=funcname(at)entry=0x16901a0 <__func__.17850> "MemoryContextAlloc") at ../src/backend/utils/error/elog.c:604
#3 0x00000000010c57c7 in MemoryContextAlloc (context=context(at)entry=0x604200032600, size=size(at)entry=8488348128) at ../src/backend/utils/mmgr/mcxt.c:1013
#4 0x0000000000db49a4 in copy_byval_expanded_array (eah=eah(at)entry=0x604200032718, oldeah=0x604200032718) at ../src/backend/utils/adt/array_expanded.c:195
#5 0x0000000000db5f7a in expand_array (arraydatum=105836584314672, parentcontext=<optimized out>, metacache=0x7ffcbd2d29c0, metacache(at)entry=0x0)
at ../src/backend/utils/adt/array_expanded.c:104
#6 0x00007f6c05a6b4d0 in plpgsql_exec_function (func=func(at)entry=0x6092004a4c58, fcinfo=fcinfo(at)entry=0x7f6c04f7efc8, simple_eval_estate=simple_eval_estate(at)entry=0x0,
simple_eval_resowner=simple_eval_resowner(at)entry=0x0, procedure_resowner=procedure_resowner(at)entry=0x0, atomic=atomic(at)entry=true)
at ../src/pl/plpgsql/src/pl_exec.c:556
#7 0x00007f6c05a76af4 in plpgsql_call_handler (fcinfo=<optimized out>) at ../src/pl/plpgsql/src/pl_handler.c:277
#8 0x00000000008b30cd in ExecInterpExpr (state=0x7f6c04fd6750, econtext=0x6072000712d0, isnull=0x7ffcbd2d2fa0) at ../src/backend/executor/execExprInterp.c:733
#9 0x00000000008a6c5f in ExecInterpExprStillValid (state=0x7f6c04fd6750, econtext=0x6072000712d0, isNull=0x7ffcbd2d2fa0)
at ../src/backend/executor/execExprInterp.c:1858
#10 0x000000000090032b in ExecEvalExprSwitchContext (isNull=0x7ffcbd2d2fa0, econtext=0x6072000712d0, state=0x7f6c04fd6750) at ../src/include/executor/executor.h:354
#11 ExecProject (projInfo=0x7f6c04fd6748) at ../src/include/executor/executor.h:388
#12 project_aggregates (aggstate=aggstate(at)entry=0x607200070d38) at ../src/backend/executor/nodeAgg.c:1377
#13 0x0000000000903eb6 in agg_retrieve_direct (aggstate=aggstate(at)entry=0x607200070d38) at ../src/backend/executor/nodeAgg.c:2520
#14 0x0000000000904074 in ExecAgg (pstate=0x607200070d38) at ../src/backend/executor/nodeAgg.c:2172
#15 0x00000000008d90e0 in ExecProcNodeFirst (node=0x607200070d38) at ../src/backend/executor/execProcnode.c:464
#16 0x00000000008c1e5f in ExecProcNode (node=0x607200070d38) at ../src/include/executor/executor.h:272
#17 ExecutePlan (estate=estate(at)entry=0x607200070a18, planstate=0x607200070d38, use_parallel_mode=false, operation=operation(at)entry=CMD_SELECT, sendTuples=true,
numberTuples=numberTuples(at)entry=0, direction=direction(at)entry=ForwardScanDirection, dest=dest(at)entry=0x7f6c051abd28, execute_once=execute_once(at)entry=true)
at ../src/backend/executor/execMain.c:1640
#18 0x00000000008c3ffb in standard_ExecutorRun (queryDesc=0x604200016998, direction=ForwardScanDirection, count=0, execute_once=<optimized out>)
at ../src/backend/executor/execMain.c:365
#19 0x00000000008c4125 in ExecutorRun (queryDesc=queryDesc(at)entry=0x604200016998, direction=direction(at)entry=ForwardScanDirection, count=count(at)entry=0,
execute_once=<optimized out>) at ../src/backend/executor/execMain.c:309
#20 0x0000000000d5d148 in PortalRunSelect (portal=portal(at)entry=0x607200028a18, forward=forward(at)entry=true, count=0, count(at)entry=9223372036854775807,
dest=dest(at)entry=0x7f6c051abd28) at ../src/backend/tcop/pquery.c:924
#21 0x0000000000d60dc8 in PortalRun (portal=portal(at)entry=0x607200028a18, count=count(at)entry=9223372036854775807, isTopLevel=isTopLevel(at)entry=true,
run_once=run_once(at)entry=true, dest=dest(at)entry=0x7f6c051abd28, altdest=altdest(at)entry=0x7f6c051abd28, qc=<optimized out>, qc(at)entry=0x7ffcbd2d3580)
at ../src/backend/tcop/pquery.c:768
#22 0x0000000000d595fd in exec_simple_query (
query_string=query_string(at)entry=0x6082000cf238 "...
#23 0x0000000000d5c72c in PostgresMain (dbname=dbname(at)entry=0x60820000b378 "postgres", username=username(at)entry=0x60820000b358 "telsasoft")
at ../src/backend/tcop/postgres.c:4632
#24 0x0000000000bddc19 in BackendRun (port=port(at)entry=0x60300000fc40) at ../src/backend/postmaster/postmaster.c:4461
#25 0x0000000000be2583 in BackendStartup (port=port(at)entry=0x60300000fc40) at ../src/backend/postmaster/postmaster.c:4189
#26 0x0000000000be2a05 in ServerLoop () at ../src/backend/postmaster/postmaster.c:1779
#27 0x0000000000be436b in PostmasterMain (argc=argc(at)entry=9, argv=argv(at)entry=0x600e0000df40) at ../src/backend/postmaster/postmaster.c:1463
#28 0x00000000009c33d5 in main (argc=9, argv=0x600e0000df40) at ../src/backend/main/main.c:200

(gdb) fr 4
#4 0x0000000000db49a4 in copy_byval_expanded_array (eah=eah(at)entry=0x604200032718, oldeah=0x604200032718) at ../src/backend/utils/adt/array_expanded.c:195
195 eah->dims = (int *) MemoryContextAlloc(objcxt, ndims * 2 * sizeof(int));
(gdb) p ndims
$1 = 1061043516

--
Justin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2023-04-14 22:04:52 Re: v16dev: invalid memory alloc request size 8488348128
Previous Message Robert Haas 2023-04-14 20:11:47 Re: allow_in_place_tablespaces vs. pg_basebackup