BUG #13334: PostGIS 2.2 crash in topology (array_contain_compare)

The following bug has been logged on the website:

Bug reference:      13334
Logged by:          Regina Obe
Email address:      lr@pcorp.us
PostgreSQL version: Unsupported/Unknown
Operating system:   Debian 6 and Mingw-w64
Description:

Since May 9th our Debian build bot has been crashing on one of our PostGIS
regression tests.

I tried the same exercise on my Mingw-w64 GCC 4.8.3 (with latest PostgreSQL
9.5 - (dated 5/22) and also have crashing in same spot.

I isoloated the offending query in PostGIS to this:

with inp as ( select 'MULTIPOINT((0 -10),(5 -10))' ::geometry as g)
select St_AsText(g), ST_Equals(totopogeom(g, 'tt', 1)::geometry, g) from
inp;


Which produces a gdb backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4252.0x3cf4]
array_contain_compare (array1=array1@entry=0xdd94200,
array2=array2@entry=0xde69db8, collation=<optimized out>,
matchall=matchall@entry=1 '\001', fn_extra=0xdeac920) at arrayfuncs.c:4116
4116                            if (isnull2)
(gdb) bt
#0  array_contain_compare (array1=array1@entry=0xdd94200,
array2=array2@entry=0xde69db8, collation=<optimized out>,
matchall=matchall@entry=1 '\001', fn_extra=0xdeac920) at arrayfuncs.c:4116
#1  0x00000000006ab084 in arraycontains (fcinfo=0xdeac958) at
arrayfuncs.c:4181
#2  0x000000000057bf4b in ExecMakeFunctionResultNoSets (fcache=0xdeac8e8,
econtext=0x48eef28, isNull=0x273da80 "", isDone=<optimized out>) at
execQual.c:2018
#3  0x000000006ab4bcb2 in exec_eval_simple_expr (rettypmod=0x273d99c,
rettype=<optimized out>, isNull=0x273da80 "", result=<synthetic pointer>,
expr=0xddf5d58, estate=0x273e100) at pl_exec.c:5385
#4  exec_eval_expr (estate=0x273e100, expr=0xddf5d58, isNull=0x273da80 "",
rettype=<optimized out>, rettypmod=0x273d99c) at pl_exec.c:4974
#5  0x000000006ab4db50 in exec_eval_boolean (estate=estate@entry=0x273e100,
expr=<optimized out>, isNull=isNull@entry=0x273da80 "") at pl_exec.c:4940
#6  0x000000006ab501d3 in exec_stmt_if (stmt=0xddf74d8, estate=0x273e100) at
pl_exec.c:1713
#7  exec_stmt (stmt=0xddf74d8, estate=0x273e100) at pl_exec.c:1464
#8  exec_stmts (estate=0x273e100, stmts=<optimized out>) at pl_exec.c:1415
#9  0x000000006ab53812 in exec_for_query (estate=estate@entry=0x273e100,
stmt=stmt@entry=0xddf57c8, portal=0x48d8e98, prefetch_ok=prefetch_ok@entry=1
'\001') at pl_exec.c:5158
#10 0x000000006ab4f89f in exec_stmt_fors (stmt=0xddf57c8, estate=0x273e100)
at pl_exec.c:2142
#11 exec_stmt (stmt=0xddf57c8, estate=0x273e100) at pl_exec.c:1484
#12 exec_stmts (estate=0x273e100, stmts=<optimized out>) at pl_exec.c:1415
#13 0x000000006ab53812 in exec_for_query (estate=estate@entry=0x273e100,
stmt=stmt@entry=0xddf44b0, portal=0x48d8d80, prefetch_ok=prefetch_ok@entry=1
'\001') at pl_exec.c:5158
#14 0x000000006ab4f89f in exec_stmt_fors (stmt=0xddf44b0, estate=0x273e100)
at pl_exec.c:2142
#15 exec_stmt (stmt=0xddf44b0, estate=0x273e100) at pl_exec.c:1484
#16 exec_stmts (estate=0x273e100, stmts=<optimized out>) at pl_exec.c:1415
#17 0x000000006ab525e2 in exec_stmt_block (estate=0x0,
estate@entry=0x273e100, block=0xa004e0 <error_context_stack>) at
pl_exec.c:1353
#18 0x000000006ab52820 in plpgsql_exec_function (func=0x4910510,
func@entry=0xddd31c0, fcinfo=0xddd31c0, fcinfo@entry=0x273e358,
simple_eval_estate=simple_eval_estate@entry=0x0) at pl_exec.c:402
#19 0x000000006ab4736b in plpgsql_call_handler (fcinfo=0x273e358) at
pl_handler.c:253
#20 0x000000000057bf4b in ExecMakeFunctionResultNoSets (fcache=0xddd3150,
econtext=0x48eee30, isNull=0x273e4a7 "", isDone=<optimized out>) at
execQual.c:2018
#21 0x000000006ab4bcb2 in exec_eval_simple_expr (rettypmod=0x273e4ac,
rettype=<optimized out>, isNull=0x273e4a7 "", result=<synthetic pointer>,
expr=0x494b270, estate=0x273e850) at pl_exec.c:5385
#22 exec_eval_expr (estate=0x273e850, expr=0x494b270, isNull=0x273e4a7 "",
rettype=<optimized out>, rettypmod=0x273e4ac) at pl_exec.c:4974
#23 0x000000006ab4dca6 in exec_assign_expr (estate=estate@entry=0x273e850,
target=0x49405f8, expr=0x494b270) at pl_exec.c:4148
#24 0x000000006ab501ac in exec_stmt_assign (stmt=<optimized out>,
stmt=<optimized out>, estate=0x273e850) at pl_exec.c:1568
#25 exec_stmt (stmt=0x494b360, estate=0x273e850) at pl_exec.c:1452
#26 exec_stmts (estate=0x273e850, stmts=<optimized out>) at pl_exec.c:1415
#27 0x000000006ab525e2 in exec_stmt_block (estate=0x0,
estate@entry=0x273e850, block=0x48eee30) at pl_exec.c:1353
#28 0x000000006ab52820 in plpgsql_exec_function (func=0x283c840,
func@entry=0x4930cb8, fcinfo=0x4930cb8, fcinfo@entry=0x273eaa8,
simple_eval_estate=simple_eval_estate@entry=0x0) at pl_exec.c:402
#29 0x000000006ab4736b in plpgsql_call_handler (fcinfo=0x273eaa8) at
pl_handler.c:253
#30 0x000000000057bf4b in ExecMakeFunctionResultNoSets (fcache=0x4930c48,
econtext=0x4926c30, isNull=0x4928200 "", isDone=<optimized out>) at
execQual.c:2018
#31 0x000000000057bef1 in ExecMakeFunctionResultNoSets (fcache=0x4927e50,
econtext=0x4926c30, isNull=0x49279e8 "", isDone=<optimized out>) at
execQual.c:1992
#32 0x000000000057bef1 in ExecMakeFunctionResultNoSets (fcache=0x4927638,
econtext=0x4926c30, isNull=0x4931b61 "\177~\177\177\177\177\177\230xƒ\002",
isDone=<optimized out>) at execQual.c:1992
#33 0x0000000000581eb0 in ExecTargetList (isDone=0x273ed1c,
itemIsDone=0x4931cd8, isnull=0x4931b60 "", values=0x4931b38,
econtext=0x4926c30, targetlist=0x4931c78) at execQual.c:5363
#34 ExecProject (projInfo=projInfo@entry=0x4931b80,
isDone=isDone@entry=0x273ed1c) at execQual.c:5578
#35 0x0000000000582300 in ExecScan (node=node@entry=0x48e34d8,
accessMtd=accessMtd@entry=0x598910 <CteScanNext>,
recheckMtd=recheckMtd@entry=0x598900 <CteScanRecheck>) at execScan.c:207
#36 0x0000000000598a53 in ExecCteScan (node=node@entry=0x48e34d8) at
nodeCtescan.c:158
#37 0x000000000057ad18 in ExecProcNode (node=node@entry=0x48e34d8) at
execProcnode.c:450
#38 0x0000000000577a6e in ExecutePlan (dest=0x49306c8, direction=<optimized
out>, numberTuples=0, sendTuples=1 '\001', operation=CMD_SELECT,
planstate=0x48e34d8, estate=0x48e2cb8) at execMain.c:1550
#39 standard_ExecutorRun (queryDesc=0x2835098, direction=<optimized out>,
count=0) at execMain.c:337
#40 0x000000000068ba68 in PortalRunSelect (portal=portal@entry=0x48d8c68,
forward=forward@entry=1 '\001', count=0, count@entry=41153104,
dest=dest@entry=0x0) at pquery.c:952
#41 0x000000000068d0c6 in PortalRun (portal=0x273eeb0,
portal@entry=0x48d8c68, count=41153104, count@entry=2147483647,
isTopLevel=isTopLevel@entry=0 '\000', dest=0x0, dest@entry=0x49306c8,
altdest=altdest@entry=0x49306c8, completionTag=0x273f210 "",
completionTag@entry=0x40000000093 <error: Cannot access memory at address
0x40000000093>) at pquery.c:796
#42 0x000000000068a964 in exec_simple_query (query_string=0x0) at
postgres.c:1104
#43 PostgresMain (argc=<optimized out>, argv=argv@entry=0x3181a8,
dbname=0x10000f000e000d <error: Cannot access memory at address
0x10000f000e000d>, username=<optimized out>) at postgres.c:4025
#44 0x000000000062a913 in BackendRun (port=0x273f400) at postmaster.c:4162
#45 SubPostmasterMain (argc=argc@entry=3, argv=argv@entry=0x27a7fa0) at
postmaster.c:4649
#46 0x00000000007c6830 in main (argc=3, argv=0x27a7fa0) at main.c:198
(gdb)


Have issue ticketed here:
http://trac.osgeo.org/postgis/ticket/3122

I should add that Paul Ramsey tried to replicate the crash on his mac
(running Clang something or other), and he does not get a crash on this
regression test.

The only thing I can think of special about this function is that it adds a
bunch of records to another table (a relations table), and returns back  a
generated id which is a key that links these records together.

I doesn't crash if only one record is inserted, but fails on all variants of
MULTI (which end up adding multiple records)