SIGABRT on 7.4.5

Started by Joe Conwayover 21 years ago2 messages
#1Joe Conway
mail@joeconway.com

I have been trying to troubleshoot a PL/R related issue on-and-off for a
few weeks now, but this morning ran into what appears to be a more
general issue related to 7.4.5 on x86_64. A full backtrace is below, and
in it you can see that PL/R is never reached (but PL/pgSQL is). What is
really odd is that the abort appears to happen because
CacheMemoryContext is invalid. I do *not* see this same failure on a
different machine with a 32 bit build (I see a PL/R related failure
there, but that's a different story...).

Any ideas? I'll request permission to provide the full script to
reproduce this to someone offlist if it will help.

Thanks,

Joe

issue=# select version();
version
----------------------------------------------------------------------------------------------------------------
PostgreSQL 7.4.5 on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
(1 row)

(gdb) bt
#0 0x000000300042dc05 in raise () from /lib64/tls/libc.so.6
#1 0x000000300042f68e in abort () from /lib64/tls/libc.so.6
#2 0x00000000005a1fb7 in ExceptionalCondition (conditionName=0x4c8f
<Address 0x4c8f out of bounds>,
errorType=0x4c8f <Address 0x4c8f out of bounds>, fileName=0x6
<Address 0x6 out of bounds>, lineNumber=-1) at assert.c:46
#3 0x00000000005b19b3 in MemoryContextSwitchTo (context=0x83b2e8) at
mcxt.c:608
#4 0x000000000059950f in CatalogCacheCreateEntry (cache=0x2a9a8b80f0,
ntp=0x265c7f8, hashValue=3646268205, hashIndex=720, negative=6 '\006')
at catcache.c:1581
#5 0x0000000000598f5a in SearchCatCacheList (cache=0x2a9a8b80f0,
nkeys=2, v1=40220384, v2=0, v3=3646268205, v4=40224760) at catcache.c:1474
#6 0x00000000004725d7 in FuncnameGetCandidates (names=0x4c8f, nargs=2)
at namespace.c:466
#7 0x0000000000492d8a in func_get_detail (funcname=0x265b740,
fargs=0x265bda0, nargs=2, argtypes=0x7fbfffc7e0, funcid=0x7fbfffc7c4,
rettype=0x7fbfffc7c8, retset=0x7fbfffc7cf "",
true_typeids=0x7fbfffc7d0) at parse_func.c:786
#8 0x0000000000492292 in ParseFuncOrColumn (pstate=0x265bbf0,
funcname=0x265b740, fargs=0x265bda0, agg_star=0 '\0', agg_distinct=0 '\0',
is_column=0 '\0') at parse_func.c:243
#9 0x0000000000491545 in transformExpr (pstate=0x265bbf0,
expr=0x265ba78) at parse_expr.c:443
#10 0x000000000049a13c in transformTargetEntry (pstate=0x265bbf0,
node=0x265ba78, expr=0x0, colname=0x0, resjunk=0 '\0') at parse_target.c:61
#11 0x000000000049a1a1 in transformTargetList (pstate=0x265bbf0,
targetlist=0x4c8f) at parse_target.c:201
#12 0x000000000047dfcd in transformSelectStmt (pstate=0x265bbf0,
stmt=0x265bb20) at analyze.c:1960
#13 0x000000000047b935 in transformStmt (pstate=0x265bbf0,
parseTree=0x265bb20, extras_before=0x7fbfffca30, extras_after=0x7fbfffca38)
at analyze.c:415
#14 0x000000000047b791 in do_parse_analyze (parseTree=0x4c8f,
pstate=0x265bbf0) at analyze.c:239
#15 0x000000000047b642 in parse_analyze (parseTree=0x265bb20,
paramTypes=0x227b148, numParams=4) at analyze.c:163
#16 0x000000000053f120 in pg_analyze_and_rewrite (parsetree=0x265bb20,
paramTypes=0x227b148, numParams=4) at postgres.c:497
#17 0x00000000004e1625 in _SPI_execute (src=0x1c0fe60 "SELECT
F_EXTEND_STYLE_DATA( $1 , $2 + $3 [ $4 ][1])", tcount=0, plan=0x265b598)
at spi.c:1054
#18 0x00000000004dfe9a in SPI_prepare (src=0x1c0fe60 "SELECT
F_EXTEND_STYLE_DATA( $1 , $2 + $3 [ $4 ][1])", nargs=4, argtypes=0x227b148)
at spi.c:295
#19 0x0000002a9b155a87 in exec_prepare_plan (estate=0x7fbfffcde0,
expr=0x1c0fe00) at pl_exec.c:1968
#20 0x0000002a9b15767c in exec_eval_expr (estate=0x7fbfffcde0,
expr=0x1c0fe00, isNull=0x7fbfffcbb3 "", rettype=0x7fbfffcbb4) at
pl_exec.c:3114
#21 0x0000002a9b156a4b in exec_assign_expr (estate=0x7fbfffcde0,
target=0x227d628, expr=0x4c8f) at pl_exec.c:2657
#22 0x0000002a9b1548de in exec_stmt_assign (estate=0x7fbfffcde0,
stmt=0x201d000) at pl_exec.c:1031
#23 0x0000002a9b154741 in exec_stmt (estate=0x7fbfffcde0,
stmt=0x201d000) at pl_exec.c:935
#24 0x0000002a9b15468b in exec_stmts (estate=0x7fbfffcde0,
stmts=0x1c0fde0) at pl_exec.c:903
#25 0x0000002a9b154b0a in exec_stmt_if (estate=0x7fbfffcde0,
stmt=0x201d020) at pl_exec.c:1139
#26 0x0000002a9b15474e in exec_stmt (estate=0x7fbfffcde0,
stmt=0x201d020) at pl_exec.c:947
#27 0x0000002a9b15468b in exec_stmts (estate=0x7fbfffcde0,
stmts=0x201d050) at pl_exec.c:903
#28 0x0000002a9b154dc8 in exec_stmt_fori (estate=0x7fbfffcde0,
stmt=0x22742f0) at pl_exec.c:1309
#29 0x0000002a9b154775 in exec_stmt (estate=0x7fbfffcde0,
stmt=0x22742f0) at pl_exec.c:959
#30 0x0000002a9b15468b in exec_stmts (estate=0x7fbfffcde0,
stmts=0x193e8a0) at pl_exec.c:903
#31 0x0000002a9b1544e1 in exec_stmt_block (estate=0x7fbfffcde0,
block=0x22743c0) at pl_exec.c:859
#32 0x0000002a9b15384f in plpgsql_exec_function (func=0x2098650,
fcinfo=0x7fbfffcf50) at pl_exec.c:325
#33 0x0000002a9b150f16 in plpgsql_call_handler (fcinfo=0x7fbfffcf50) at
pl_handler.c:124
#34 0x00000000004d0af7 in ExecMakeTableFunctionResult
(funcexpr=0x2241c60, econtext=0x2240b50, expectedDesc=0x22413d8,
returnDesc=0x7fbfffd0e0)
at execQual.c:1057
#35 0x00000000004dafe5 in FunctionNext (node=0x2240a38) at
nodeFunctionscan.c:78
#36 0x00000000004d3270 in ExecScan (node=0x2240a38, accessMtd=0x4daf40
<FunctionNext>) at execScan.c:98
#37 0x00000000004cf3cd in ExecProcNode (node=0x2240a38) at
execProcnode.c:322
#38 0x00000000004cdcf0 in ExecutePlan (estate=0x2240808,
planstate=0x2240a38, operation=CMD_SELECT, numberTuples=10, direction=6,
dest=0x7908c0)
at execMain.c:1103
#39 0x00000000004ccfe5 in ExecutorRun (queryDesc=0x2245650,
direction=ForwardScanDirection, count=10) at execMain.c:249
#40 0x0000000000542aff in PortalRunSelect (portal=0x8868a8, forward=1
'\001', count=10, dest=0x7908c0) at pquery.c:590
#41 0x000000000054318f in PortalRunFetch (portal=0x8868a8,
fdirection=FETCH_FORWARD, count=10, dest=0x7908c0) at pquery.c:961
#42 0x00000000004e1b99 in _SPI_cursor_operation (portal=0x8868a8,
forward=1 '\001', count=10, dest=0x7908c0) at spi.c:1315
#43 0x0000002a9b154f51 in exec_stmt_fors (estate=0x7fbfffd450,
stmt=0x1ab4580) at pl_exec.c:1391
#44 0x0000002a9b154782 in exec_stmt (estate=0x7fbfffd450,
stmt=0x1ab4580) at pl_exec.c:963
#45 0x0000002a9b15468b in exec_stmts (estate=0x7fbfffd450,
stmts=0x18aa710) at pl_exec.c:903
#46 0x0000002a9b1544e1 in exec_stmt_block (estate=0x7fbfffd450,
block=0x18aa7a0) at pl_exec.c:859
#47 0x0000002a9b15384f in plpgsql_exec_function (func=0x1ae48e0,
fcinfo=0x7fbfffd580) at pl_exec.c:325
#48 0x0000002a9b150f16 in plpgsql_call_handler (fcinfo=0x7fbfffd580) at
pl_handler.c:124
#49 0x00000000004d0976 in ExecMakeFunctionResult (fcache=0x2105108,
econtext=0x2105000, isNull=0x7fbfffd757 "", isDone=0x2105798) at
execQual.c:907
#50 0x00000000004d23a7 in ExecEvalExpr (expression=0x2105108,
econtext=0x4c8f, isNull=0x6 <Address 0x6 out of bounds>,
isDone=0xffffffffffffffff)
at execQual.c:2253
#51 0x00000000004d2f7f in ExecTargetList (targetlist=0x21055c0,
targettype=0x21055f8, econtext=0x2105000, values=0x2105748,
nulls=0x2105770 "\210~)\002", itemIsDone=0x2105798,
isDone=0x7fbfffd7b4) at execQual.c:2984
#52 0x00000000004d31b6 in ExecProject (projInfo=0x4c8f, isDone=0x0) at
execQual.c:3130
#53 0x00000000004db544 in ExecResult (node=0x2104ee8) at nodeResult.c:155
#54 0x00000000004cf364 in ExecProcNode (node=0x2104ee8) at
execProcnode.c:295
#55 0x00000000004cdcf0 in ExecutePlan (estate=0x2104cb8,
planstate=0x2104ee8, operation=CMD_SELECT, numberTuples=1, direction=6,
dest=0x7908c0)
at execMain.c:1103
#56 0x00000000004ccfe5 in ExecutorRun (queryDesc=0x209a7d0,
direction=ForwardScanDirection, count=1) at execMain.c:249
#57 0x00000000004e1a3a in _SPI_pquery (queryDesc=0x209a7d0, runit=-1 '',
useCurrentSnapshot=6 '\006', tcount=1) at spi.c:1254
#58 0x00000000004e1947 in _SPI_execute_plan (plan=0x4c8f,
Values=0x2235080, Nulls=0x2098150 "e", useCurrentSnapshot=0 '\0',
tcount=1) at spi.c:1201
#59 0x00000000004dfd33 in SPI_execp (plan=0x2235028, Values=0x1ebc808,
Nulls=0x1c09558 " \177~\177\177\177\177\177\177\177\177\177\220�210",
tcount=1) at spi.c:241
#60 0x0000002a9b157718 in exec_run_select (estate=0x7fbfffdc00,
expr=0x140a770, maxtuples=1, portalP=0x0) at pl_exec.c:3217
#61 0x0000002a9b155125 in exec_stmt_select (estate=0x7fbfffdc00,
stmt=0x24990b0) at pl_exec.c:1519
#62 0x0000002a9b15478f in exec_stmt (estate=0x7fbfffdc00,
stmt=0x24990b0) at pl_exec.c:967
#63 0x0000002a9b15468b in exec_stmts (estate=0x7fbfffdc00,
stmts=0x24891f0) at pl_exec.c:903
#64 0x0000002a9b154fab in exec_stmt_fors (estate=0x7fbfffdc00,
stmt=0x2539cb0) at pl_exec.c:1419
#65 0x0000002a9b154782 in exec_stmt (estate=0x7fbfffdc00,
stmt=0x2539cb0) at pl_exec.c:963
#66 0x0000002a9b15468b in exec_stmts (estate=0x7fbfffdc00,
stmts=0x13b32a0) at pl_exec.c:903
#67 0x0000002a9b154b3d in exec_stmt_loop (estate=0x7fbfffdc00,
stmt=0x2569950) at pl_exec.c:1158
#68 0x0000002a9b15475b in exec_stmt (estate=0x7fbfffdc00,
stmt=0x2569950) at pl_exec.c:951
#69 0x0000002a9b15468b in exec_stmts (estate=0x7fbfffdc00,
stmts=0x2292aa0) at pl_exec.c:903
#70 0x0000002a9b1544e1 in exec_stmt_block (estate=0x7fbfffdc00,
block=0x2599db0) at pl_exec.c:859
#71 0x0000002a9b15384f in plpgsql_exec_function (func=0x22a9190,
fcinfo=0x7fbfffdd30) at pl_exec.c:325
#72 0x0000002a9b150f16 in plpgsql_call_handler (fcinfo=0x7fbfffdd30) at
pl_handler.c:124
#73 0x00000000004d0976 in ExecMakeFunctionResult (fcache=0x88f0a8,
econtext=0x88efa0, isNull=0x7fbfffdf07 "", isDone=0x88f558) at
execQual.c:907
#74 0x00000000004d23a7 in ExecEvalExpr (expression=0x88f0a8,
econtext=0x4c8f, isNull=0x6 <Address 0x6 out of bounds>,
isDone=0xffffffffffffffff)
at execQual.c:2253
#75 0x00000000004d2f7f in ExecTargetList (targetlist=0x88f380,
targettype=0x88f3b8, econtext=0x88efa0, values=0x88f508,
nulls=0x88f530 "\177~", '\177' <repeats 14 times>, "\200\237\205",
itemIsDone=0x88f558, isDone=0x7fbfffdf64) at execQual.c:2984
#76 0x00000000004d31b6 in ExecProject (projInfo=0x4c8f, isDone=0x0) at
execQual.c:3130
#77 0x00000000004db544 in ExecResult (node=0x88ee88) at nodeResult.c:155
#78 0x00000000004cf364 in ExecProcNode (node=0x88ee88) at execProcnode.c:295
#79 0x00000000004cdcf0 in ExecutePlan (estate=0x88ec58,
planstate=0x88ee88, operation=CMD_SELECT, numberTuples=0, direction=6,
dest=0x8827b8)
at execMain.c:1103
#80 0x00000000004ccfe5 in ExecutorRun (queryDesc=0x88c838,
direction=ForwardScanDirection, count=0) at execMain.c:249
#81 0x0000000000542aff in PortalRunSelect (portal=0x886678, forward=1
'\001', count=0, dest=0x8827b8) at pquery.c:590
---Type <return> to continue, or q <return> to quit---
#82 0x0000000000542881 in PortalRun (portal=0x886678,
count=9223372036854775807, dest=0x8827b8, altdest=0x8827b8,
completionTag=0x7fbfffe180 "")
at pquery.c:478
#83 0x000000000053f53e in exec_simple_query (query_string=0x881f48
"select f_temp(1,10000);") at postgres.c:873
#84 0x000000000054166a in PostgresMain (argc=4, argv=0x7ff020,
username=0x7fefd0 "postgres") at postgres.c:2871
#85 0x000000000051b584 in BackendFork (port=0x80c710) at postmaster.c:2564
#86 0x000000000051b022 in BackendStartup (port=0x80c710) at
postmaster.c:2207
#87 0x000000000051990b in ServerLoop () at postmaster.c:1119
#88 0x00000000005190b7 in PostmasterMain (argc=7, argv=0x7fded0) at
postmaster.c:897
#89 0x00000000004ea890 in main (argc=7, argv=0x7fbffff2c8) at main.c:214

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Joe Conway (#1)
Re: SIGABRT on 7.4.5

Joe Conway <mail@joeconway.com> writes:

I have been trying to troubleshoot a PL/R related issue on-and-off for a
few weeks now, but this morning ran into what appears to be a more
general issue related to 7.4.5 on x86_64. A full backtrace is below, and
in it you can see that PL/R is never reached (but PL/pgSQL is). What is
really odd is that the abort appears to happen because
CacheMemoryContext is invalid.

It could hardly not have been set up yet, so I'm betting that this
indicates a memory-stomp problem somewhere that happens to be hitting
part of the CacheMemoryContext structure.

I do *not* see this same failure on a
different machine with a 32 bit build

Not too surprising; could be related to struct sizes, padding, trying to
cram a 64-bit pointer into a 32-bit field, who knows what.

Any ideas? I'll request permission to provide the full script to
reproduce this to someone offlist if it will help.

The odds are that it couldn't be reproduced except on the same
architecture. I do have access to some x86_64 machines at Red Hat,
though, so I can take a look if you can send me a test case.

regards, tom lane