On 9/12/12 1:50 AM, Tom Lane wrote:
Marko Tiikkaja <pgm...@joh.to> writes:
Joel Jacobson managed to narrow it down to this test case, which crashes
consistently on Ubuntu 12.04 both with and without your patch. I,
however, wasn't able to reproduce the problem on my OS X Mountain Lion.
Doesn't reproduce for me either ...
Ok, I can reproduce it on my Ubuntu virtual machine.
The problem looks like this:
#0 free_plperl_function (prodesc=0x24195a0) at plperl.c:2428
#1 0x00007ff47babc045 in plperl_call_handler (fcinfo=0x247c160) at
plperl.c:1710
#2 0x00000000005663fa in ExecMakeFunctionResult (fcache=0x247c0f0,
econtext=0x247bf00, isNull=0x247ca78 "", isDone=0x247cb90) at
execQual.c:1917
#3 0x0000000000568942 in ExecTargetList (isDone=0x7fff1402fc0c,
itemIsDone=0x247cb90, isnull=0x247ca78 "", values=0x247ca60,
econtext=0x247bf00, targetlist=0x247cb60) at execQual.c:5210
#4 ExecProject (projInfo=<optimized out>, isDone=0x7fff1402fc0c) at
execQual.c:5425
#5 0x0000000000578aea in ExecResult (node=0x247bdf0) at nodeResult.c:155
#6 0x0000000000561b18 in ExecProcNode (node=0x247bdf0) at
execProcnode.c:367
#7 0x000000000055ef2a in ExecutePlan (dest=0xad4600,
direction=<optimized out>, numberTuples=0, sendTuples=1 '\001',
operation=CMD_SELECT, planstate=0x247bdf0, estate=0x247bce0) at
execMain.c:1440
#8 standard_ExecutorRun (queryDesc=0x244f6d0, direction=<optimized
out>, count=0) at execMain.c:314
#9 0x000000000058192d in _SPI_pquery (tcount=<optimized out>,
fire_triggers=1 '\001', queryDesc=<optimized out>) at spi.c:2110
#10 _SPI_execute_plan (paramLI=0x245e1f0, snapshot=<optimized out>,
crosscheck_snapshot=0x0, read_only=0 '\000', fire_triggers=1 '\001',
tcount=0, plan=<optimized out>) at spi.c:1922
#11 0x0000000000581e57 in SPI_execute_plan_with_paramlist
(plan=0x2476c30, params=0x245e1f0, read_only=0 '\000', tcount=0) at
spi.c:423
#12 0x00007ff47b0c7075 in exec_run_select (estate=0x7fff14030270,
expr=0x24569f0, maxtuples=0, portalP=0x0) at pl_exec.c:4573
#13 0x00007ff47b0ca7b4 in exec_stmt_perform (estate=0x7fff14030270,
stmt=<optimized out>) at pl_exec.c:1413
#14 exec_stmt (stmt=0x2456ab0, estate=0x7fff14030270) at pl_exec.c:1289
#15 exec_stmts (estate=0x7fff14030270, stmts=<optimized out>) at
pl_exec.c:1248
#16 0x00007ff47b0cce59 in exec_stmt_block (estate=0x7fff14030270,
block=0x2457448) at pl_exec.c:1047
#17 0x00007ff47b0ca798 in exec_stmt (stmt=0x2457448,
estate=0x7fff14030270) at pl_exec.c:1281
#18 exec_stmts (estate=0x7fff14030270, stmts=<optimized out>) at
pl_exec.c:1248
#19 0x00007ff47b0ccfcc in exec_stmt_block (estate=0x7fff14030270,
block=0x2457508) at pl_exec.c:1186
#20 0x00007ff47b0cda37 in plpgsql_exec_function (func=0x243a140,
fcinfo=0x7fff14030580) at pl_exec.c:324
#21 0x00007ff47b0c26d3 in plpgsql_call_handler (fcinfo=0x7fff14030580)
at pl_handler.c:122
#22 0x0000000000566d4d in ExecMakeTableFunctionResult
(funcexpr=0x2443368, econtext=0x24428b0, expectedDesc=0x2443110,
randomAccess=0 '\000') at execQual.c:2146
#23 0x0000000000578381 in FunctionNext (node=0x24427a0) at
nodeFunctionscan.c:65
#24 0x0000000000568dde in ExecScanFetch (recheckMtd=0x578300
<FunctionRecheck>, accessMtd=0x578310 <FunctionNext>, node=0x24427a0) at
execScan.c:82
#25 ExecScan (node=0x24427a0, accessMtd=0x578310 <FunctionNext>,
recheckMtd=0x578300 <FunctionRecheck>) at execScan.c:132
#26 0x0000000000561a78 in ExecProcNode (node=0x24427a0) at
execProcnode.c:416
#27 0x000000000055ef2a in ExecutePlan (dest=0xad4600,
direction=<optimized out>, numberTuples=0, sendTuples=1 '\001',
operation=CMD_SELECT, planstate=0x24427a0, estate=0x2442690) at
execMain.c:1440
#28 standard_ExecutorRun (queryDesc=0x243f700, direction=<optimized
out>, count=0) at execMain.c:314
#29 0x000000000058192d in _SPI_pquery (tcount=<optimized out>,
fire_triggers=1 '\001', queryDesc=<optimized out>) at spi.c:2110
#30 _SPI_execute_plan (paramLI=0x243f670, snapshot=<optimized out>,
crosscheck_snapshot=0x0, read_only=0 '\000', fire_triggers=1 '\001',
tcount=0, plan=<optimized out>) at spi.c:1922
#31 0x0000000000581f39 in SPI_execute_plan (plan=0x23ee750,
Values=0x243df38, Nulls=0x24376b0 " RCHAR", read_only=0 '\000',
tcount=0) at spi.c:391
#32 0x00007ff47babce2d in plperl_spi_exec_prepared (query=0x2437690
"0x22930e0", attr=0x0, argc=2, argv=0x243df18) at plperl.c:3425
#33 0x00007ff47babe810 in XS__spi_exec_prepared (my_perl=<optimized
out>, cv=<optimized out>) at SPI.xs:141
#34 0x00007ff47b7e67ff in Perl_pp_entersub (my_perl=0x237d800) at
pp_hot.c:3046
#35 0x00007ff47b7ddc96 in Perl_runops_standard (my_perl=0x237d800) at
run.c:41
#36 0x00007ff47b77959e in Perl_call_sv (my_perl=0x237d800, sv=0x24017f8,
flags=10) at perl.c:2647
#37 0x00007ff47bab5f62 in plperl_call_perl_func (desc=0x24195a0,
fcinfo=0x242fa90) at plperl.c:2056
#38 0x00007ff47baba45b in plperl_func_handler (fcinfo=0x242fa90) at
plperl.c:2196
#39 plperl_call_handler (fcinfo=0x242fa90) at plperl.c:1705
#40 0x00000000005663fa in ExecMakeFunctionResult (fcache=0x242fa20,
econtext=0x242f830, isNull=0x24303a8 "", isDone=0x24304c0) at
execQual.c:1917
#41 0x0000000000568942 in ExecTargetList (isDone=0x7fff140312fc,
itemIsDone=0x24304c0, isnull=0x24303a8 "", values=0x2430390,
econtext=0x242f830, targetlist=0x2430490) at execQual.c:5210
#42 ExecProject (projInfo=<optimized out>, isDone=0x7fff140312fc) at
execQual.c:5425
#43 0x0000000000578aea in ExecResult (node=0x242f720) at nodeResult.c:155
#44 0x0000000000561b18 in ExecProcNode (node=0x242f720) at
execProcnode.c:367
#45 0x000000000055ef2a in ExecutePlan (dest=0x2429a80,
direction=<optimized out>, numberTuples=0, sendTuples=1 '\001',
operation=CMD_SELECT, planstate=0x242f720, estate=0x242f610) at
execMain.c:1440
#46 standard_ExecutorRun (queryDesc=0x22ae450, direction=<optimized
out>, count=0) at execMain.c:314
#47 0x0000000000629317 in PortalRunSelect (portal=0x22abc30,
forward=<optimized out>, count=0, dest=0x2429a80) at pquery.c:943
#48 0x000000000062a6a0 in PortalRun (portal=0x22abc30,
count=9223372036854775807, isTopLevel=1 '\001', dest=0x2429a80,
altdest=0x2429a80, completionTag=0x7fff14031740 "") at pquery.c:787
#49 0x000000000062698c in exec_simple_query (query_string=0x233b200
"SELECT func0003();") at postgres.c:1020
#50 PostgresMain (argc=<optimized out>, argv=<optimized out>,
username=<optimized out>) at postgres.c:3968
#51 0x00000000005eba29 in BackendRun (port=0x22b5c70) at postmaster.c:3617
#52 BackendStartup (port=0x22b5c70) at postmaster.c:3302
#53 ServerLoop () at postmaster.c:1466
#54 0x00000000005ec34c in PostmasterMain (argc=<optimized out>,
argv=0x228b540) at postmaster.c:1127
#55 0x0000000000453de0 in main (argc=1, argv=0x228b540) at main.c:199
What happens is that free_plperl_function() for some reason gets called
with the prodesc of func0003. Later on, func0003 wants to get rid of
his prodesc and I get a crash. What's weird about this is that
current_call_data->prodesc actually points to the correct prodesc (the
one of func0005), but still somehow something different is passed to
free_plperl_function().
Anything I can do to help further, let me know.
Regards,
Marko Tiikkaja
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
