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


Thu, 30 Sep 2004 11:29:25 -0700
Joe Conway <mail@joeconway.com>
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

Thu, 30 Sep 2004 15:03:24 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: SIGABRT on 7.4.5 