BUG #7656: PL/Perl SPI_freetuptable() segfault

The following bug has been logged on the website:

Bug reference: 7656
Logged by: Marko Tiikkaja
Email address: pgmail(at)joh(dot)to
PostgreSQL version: 9.1.6
Operating system: OS X
Description:

Hi,

I have a reproducible segmentation fault in PL/Perl. I have yet to narrow
down the test case to something sensible, but I do have a backtrace:

219 while (context->firstchild != NULL)
(gdb) bt
#0 0x0000000104e90782 in MemoryContextDeleteChildren (context=0x1000002bd)
at mcxt.c:219
#1 0x0000000104e906a8 in MemoryContextDelete (context=0x1000002bd) at
mcxt.c:174
#2 0x0000000104bbefb5 in SPI_freetuptable (tuptable=0x7f9ae4289230) at
spi.c:1003
#3 0x000000011ec9928b in plperl_spi_execute_fetch_result
(tuptable=0x7f9ae4289230, processed=1, status=-6) at plperl.c:2900
#4 0x000000011ec98f27 in plperl_spi_exec (query=0x7f9ae4155f80
"0x7f9ae3e3fe50", limit=-439796840) at plperl.c:2821
#5 0x000000011ec9b5f7 in XS__spi_exec_query (my_perl=0x7f9ae40cce00,
cv=0x7f9ae4148e90) at SPI.c:69
#6 0x000000011ed19abd in Perl_pp_entersub ()
#7 0x000000011ed11ee1 in Perl_runops_standard ()
#8 0x000000011ecc36a3 in Perl_call_sv ()
#9 0x000000011ec949c7 in plperl_call_perl_func (desc=0x7f9ae42c7400,
fcinfo=0x7fff5b266790) at plperl.c:2066
#10 0x000000011ec96cda in plperl_func_handler (fcinfo=0x7fff5b266790) at
plperl.c:2199
#11 0x000000011ec91f62 in plperl_call_handler (fcinfo=0x7fff5b266790) at
plperl.c:1710
#12 0x000000011ec92fd8 in plperlu_call_handler (fcinfo=0x7fff5b266790) at
plperl.c:1911
#13 0x0000000104e6671a in fmgr_security_definer (fcinfo=0x7fff5b266790) at
fmgr.c:975
#14 0x0000000104b8bd8b in ExecMakeTableFunctionResult
(funcexpr=0x7f9ae421f8b0, econtext=0x7f9ae421f450,
expectedDesc=0x7f9ae421f770, randomAccess=0 '\0') at execQual.c:2146
#15 0x0000000104baf39c in FunctionNext (node=0x7f9ae421f340) at
nodeFunctionscan.c:65
#16 0x0000000104b94e4d in ExecScanFetch (node=0x7f9ae421f340,
accessMtd=0x104baf320 <FunctionNext>, recheckMtd=0x104baf420
<FunctionRecheck>) at execScan.c:82
#17 0x0000000104b94b73 in ExecScan (node=0x7f9ae421f340,
accessMtd=0x104baf320 <FunctionNext>, recheckMtd=0x104baf420
<FunctionRecheck>) at execScan.c:132
#18 0x0000000104baf479 in ExecFunctionScan (node=0x7f9ae421f340) at
nodeFunctionscan.c:105
#19 0x0000000104b87235 in ExecProcNode (node=0x7f9ae421f340) at
execProcnode.c:416
#20 0x0000000104b8481e in ExecutePlan (estate=0x7f9ae421f230,
planstate=0x7f9ae421f340, operation=CMD_SELECT, sendTuples=1 '\001',
numberTuples=0, direction=ForwardScanDirection, dest=0x7f9ae401f640) at
execMain.c:1440
#21 0x0000000104b82827 in standard_ExecutorRun (queryDesc=0x7f9ae4334d90,
direction=ForwardScanDirection, count=0) at execMain.c:314
#22 0x000000010530f6d4 in explain_ExecutorRun ()
#23 0x0000000104b826d1 in ExecutorRun (queryDesc=0x7f9ae4334d90,
direction=ForwardScanDirection, count=0) at execMain.c:260
#24 0x0000000104cf863b in PortalRunSelect (portal=0x7f9ae403f030, forward=1
'\001', count=0, dest=0x7f9ae401f640) at pquery.c:943
#25 0x0000000104cf820b in PortalRun (portal=0x7f9ae403f030,
count=9223372036854775807, isTopLevel=1 '\001', dest=0x7f9ae401f640,
altdest=0x7f9ae401f640, completionTag=0x7fff5b26724f "") at pquery.c:787
#26 0x0000000104cf251a in exec_execute_message (portal_name=0x7f9ae401f230
"", max_rows=9223372036854775807) at postgres.c:1965
#27 0x0000000104cf6005 in PostgresMain (argc=2, argv=0x7f9ae401ba90,
username=0x7f9ae401ba60 "marko") at postgres.c:4025
#28 0x0000000104c8b0ff in BackendRun (port=0x7f9ae3c06050) at
postmaster.c:3617
#29 0x0000000104c8a444 in BackendStartup (port=0x7f9ae3c06050) at
postmaster.c:3302
#30 0x0000000104c869ac in ServerLoop () at postmaster.c:1466
#31 0x0000000104c85bd0 in PostmasterMain (argc=3, argv=0x7f9ae3c03ce0) at
postmaster.c:1127
#32 0x0000000104bd807b in main (argc=3, argv=0x7f9ae3c03ce0) at main.c:199

I'm not running exactly 9.1.6; this is commit ff8f7103b559d8f19731157aca38
from REL9_1_STABLE.

While trying to narrow down the test case I noticed what the problem was: I
was calling spi_execute_query() instead of spi_execute_prepared(). I can't
reproduce it on a smaller test case (I get the expected "syntax error"), but
I still have the old function available if that seems necessary.