Re: BUG #7516: PL/Perl crash

From: Marko Tiikkaja <pgmail(at)joh(dot)to>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7516: PL/Perl crash
Date: 2012-09-12 11:01:40
Message-ID: 50506B94.5040003@joh.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 9/12/12 1:50 AM, Tom Lane wrote:
> Marko Tiikkaja <pgmail(at)joh(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message amit.kapila 2012-09-12 11:47:16 BUG #7533: Client is not able to connect cascade standby incase basebackup is taken from hot standby
Previous Message Dimitri Fontaine 2012-09-12 09:51:43 Re: BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations