Re: pg13.2: invalid memory alloc request size NNNN - Mailing list pgsql-hackers

On Thu, Feb 11, 2021 at 07:48:37PM -0600, Justin Pryzby wrote:
> #3  0x00000000009fb149 in text_to_cstring (t=0x2aaae8023010) at varlena.c:212
> 212             result = (char *) palloc(len + 1);
> 
> (gdb) l
> 207             /* must cast away the const, unfortunately */
> 208             text       *tunpacked = pg_detoast_datum_packed(unconstify(text *, t));
> 209             int                     len = VARSIZE_ANY_EXHDR(tunpacked);
> 210             char       *result;
> 211
> 212             result = (char *) palloc(len + 1);
> 
> (gdb) p len
> $1 = -4

I reproduced this with a simpler query:

ts=# explain analyze SELECT CASE rattype::integer WHEN NNNNN THEN '.......' END AS ra_type FROM t WHERE tm BETWEEN
'2021-02-1123:55' AND '2021-02-11 23:56';
 

#0  pg_re_throw () at elog.c:1714
#1  0x00000000008aa0f6 in errfinish (filename=<optimized out>, filename@entry=0xa3ff9e "mcxt.c",
lineno=lineno@entry=959,funcname=funcname@entry=0xa400f8 <__func__.7429> "palloc") at elog.c:502
 
#2  0x00000000008d2344 in palloc (size=18446744073709551613) at mcxt.c:959
#3  0x00000000008819ab in text_to_cstring (t=0x2aaad43ad008) at varlena.c:212
#4  0x0000000000629b1d in ExecInterpExpr (state=0x1df4350, econtext=0x1df34b8, isnull=<optimized out>) at
execExprInterp.c:1112
#5  0x0000000000636c22 in ExecEvalExprSwitchContext (isNull=0x7ffc2a0ed0d7, econtext=0x1df34b8, state=0x1df4350) at
../../../src/include/executor/executor.h:316
#6  ExecProject (projInfo=0x1df4348) at ../../../src/include/executor/executor.h:350
#7  ExecScan (node=<optimized out>, accessMtd=0x644170 <BitmapHeapNext>, recheckMtd=0x644b40 <BitmapHeapRecheck>) at
execScan.c:238
#8  0x0000000000633ef8 in ExecProcNodeInstr (node=0x1df32a8) at execProcnode.c:466
#9  0x000000000062d192 in ExecProcNode (node=0x1df32a8) at ../../../src/include/executor/executor.h:248
#10 ExecutePlan (execute_once=<optimized out>, dest=0x9fc360 <donothingDR>, direction=<optimized out>, numberTuples=0,
sendTuples=true,operation=CMD_SELECT, use_parallel_mode=<optimized out>, planstate=0x1df32a8,
 
    estate=0x1df3078) at execMain.c:1632

(gdb) p (varattrib_1b)t
$16 = {va_header = 8 '\b', va_data = 0x7ffcf4bd4bb9 "\200}\310\324\177"}

(gdb) p ((varattrib_4b)t)->va_4byte->va_header
$22 = 3363667976

(gdb) down
#4  0x00000000009fbf05 in textout (fcinfo=0x2fd5e48) at varlena.c:557
557             PG_RETURN_CSTRING(TextDatumGetCString(txt));
(gdb) p *fcinfo 
$1 = {flinfo = 0x2fd5df8, context = 0x0, resultinfo = 0x0, fncollation = 0, isnull = false, nargs = 1, args =
0x2fd5e68}
(gdb) p *fcinfo->args
$2 = {value = 140551873462280, isnull = false}

Just now, this cluster was killed while creating an index on a separate table:

Program received signal SIGSEGV, Segmentation fault.
0x00007ff549e53f33 in __memcpy_sse2 () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ff549e53f33 in __memcpy_sse2 () from /lib64/libc.so.6
#1  0x00000000009fee14 in varstrfastcmp_locale (a1p=0x363e424 "", len1=-4, a2p=0x3a81a51 "", len2=15, ssup=0x2e100c8)
atvarlena.c:2337
 
#2  0x00000000009febbd in varlenafastcmp_locale (x=56878112, y=61348432, ssup=0x2e100c8) at varlena.c:2249
#3  0x0000000000a6ea4d in ApplySortComparator (datum1=56878112, isNull1=false, datum2=61348432, isNull2=false,
ssup=0x2e100c8)at ../../../../src/include/utils/sortsupport.h:224
 
#4  0x0000000000a7938f in comparetup_index_btree (a=0x7ff53b375798, b=0x7ff53a4a5048, state=0x2e0fc28) at
tuplesort.c:4147
#5  0x0000000000a6f237 in qsort_tuple (a=0x7ff53a4a5048, n=1071490, cmp_tuple=0xa79318 <comparetup_index_btree>,
state=0x2e0fc28)at qsort_tuple.c:150
 
#6  0x0000000000a74b53 in tuplesort_sort_memtuples (state=0x2e0fc28) at tuplesort.c:3490
#7  0x0000000000a7427b in dumptuples (state=0x2e0fc28, alltuples=true) at tuplesort.c:3156
#8  0x0000000000a72397 in tuplesort_performsort (state=0x2e0fc28) at tuplesort.c:2038
#9  0x00000000005011d2 in _bt_leafbuild (btspool=0x2e139a8, btspool2=0x0) at nbtsort.c:553
#10 0x0000000000500d56 in btbuild (heap=0x7ff54afef410, index=0x7ff54aff5250, indexInfo=0x2d5e8e8) at nbtsort.c:333
#11 0x00000000005787d1 in index_build (heapRelation=0x7ff54afef410, indexRelation=0x7ff54aff5250, indexInfo=0x2d5e8e8,
isreindex=false,parallel=true) at index.c:2962
 
#12 0x0000000000575ba7 in index_create (heapRelation=0x7ff54afef410, indexRelationName=0x2d624a8
"cdrs_huawei_sgsnpdprecord_2021_02_12_servedimsi_idx",indexRelationId=3880431557, parentIndexRelid=0,
parentConstraintId=0,
    relFileNode=0, indexInfo=0x2d5e8e8, indexColNames=0x2e12ae0, accessMethodObjectId=403, tableSpaceId=3787872951,
collationObjectId=0x2e12c08,classObjectId=0x2e12c50, coloptions=0x2e12c68, reloptions=48311088, flags=0,
 
    constr_flags=0, allow_system_table_mods=false, is_internal=false, constraintId=0x7ffc8964c23c) at index.c:1231
#13 0x0000000000651cd9 in DefineIndex (relationId=3840862493, stmt=0x2d5e7a8, indexRelationId=0, parentIndexId=0,
parentConstraintId=0,is_alter_table=false, check_rights=true, check_not_in_use=true, skip_build=false,
 
    quiet=false) at indexcmds.c:1105
#14 0x00000000008c620d in ProcessUtilitySlow (pstate=0x2d62398, pstmt=0x2d3bd78,
    queryString=0x2d3ae48 "CREATE INDEX ii ON tt (cc) WITH (FILLFACTOR=100) TABLESPACE cdr_index;",
    context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x2d3c038, qc=0x7ffc8964cdd0) at utility.c:1517

(gdb) up
#2  0x00000000009febbd in varlenafastcmp_locale (x=56878112, y=61348432, ssup=0x2e100c8) at varlena.c:2249
2249            result = varstrfastcmp_locale(a1p, len1, a2p, len2, ssup);

(gdb) l
2244            a2p = VARDATA_ANY(arg2);
2245
2246            len1 = VARSIZE_ANY_EXHDR(arg1);
2247            len2 = VARSIZE_ANY_EXHDR(arg2);
2248
2249            result = varstrfastcmp_locale(a1p, len1, a2p, len2, ssup);
2250
2251            /* We can't afford to leak memory here. */
2252            if (PointerGetDatum(arg1) != x)
2253                    pfree(arg1);

(gdb) p len1
$1 = -4
(gdb) p len2
$2 = 15

And now I was able to crash again by creating index on a 3rd, similar table.

FYI, this is running centos 7.8.