Re: BUG #7516: PL/Perl crash - Mailing list pgsql-bugs
From | Marko Tiikkaja |
---|---|
Subject | Re: BUG #7516: PL/Perl crash |
Date | |
Msg-id | 50506B94.5040003@joh.to Whole thread Raw |
In response to | Re: BUG #7516: PL/Perl crash (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: BUG #7516: PL/Perl crash
|
List | pgsql-bugs |
On 9/12/12 1:50 AM, Tom Lane wrote: > Marko Tiikkaja <pgmail@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
pgsql-bugs by date: