The following bug has been logged on the website: Bug reference: 7656 Logged by: Marko Tiikkaja Email address: pgm...@joh.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. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs