SIGSEGV in geos_intersects

[lefty]

Hello! We are trying to upgrade to PostgreSQL 9.3 & Postgis 2.1 and we are now blocked by a reproducible crash "in geos_intersects at lwgeom_geos.c:2624". Here is the strack trace:

#0  0x00007f4942d9d946 in geos_intersects (fcinfo=0x1618600) at
lwgeom_geos.c:2624
#1  0x000000000058b01b in ExecMakeFunctionResult (fcache=0x1618590,
econtext=0x1617a40, isNull=0x1619008 "", isDone=<optimized out>) at
execQual.c:1927
#2  0x0000000000586b36 in ExecEvalAnd (andExpr=<optimized out>,
econtext=0x1617a40, isNull=0x1619008 "", isDone=<optimized out>) at
execQual.c:2767
#3  0x000000000058d4f6 in ExecTargetList (isDone=0x7fff39325c1c,
itemIsDone=0x1619120, isnull=0x1619008 "", values=0x1618ff0,
econtext=0x1617a40,
    targetlist=0x16190f0) at execQual.c:5221
#4  ExecProject (projInfo=<optimized out>, isDone=0x7fff39325c1c) at
execQual.c:5436
#5  0x000000000059e5fb in ExecResult (node=0x1617930) at nodeResult.c:155
#6  0x00000000005866b8 in ExecProcNode (node=0x1617930) at
execProcnode.c:372
#7  0x0000000000583fe2 in ExecutePlan (dest=0x1611730,
direction=<optimized out>, numberTuples=1, sendTuples=1 '\001',
operation=CMD_SELECT,
    planstate=0x1617930, estate=0x1617820) at execMain.c:1395
#8  standard_ExecutorRun (queryDesc=0x1613960, direction=<optimized
out>, count=1) at execMain.c:303
#9  0x0000000000591411 in postquel_getnext (es=<optimized out>,
fcache=<optimized out>) at functions.c:844
#10 fmgr_sql (fcinfo=<optimized out>) at functions.c:1140
#11 0x0000000000589bd8 in ExecMakeFunctionResultNoSets
(fcache=0x7f494441a170, econtext=0x7f4944419a90, isNull=0x7fff39325e2f
"", isDone=<optimized out>)
    at execQual.c:1993
#12 0x000000000058d30f in ExecQual (qual=<optimized out>,
econtext=0x7f4944419a90, resultForNull=0 '\000') at execQual.c:5123
#13 0x000000000059763a in ExecHashJoin (node=0x7f4944419980) at
nodeHashjoin.c:393
#14 0x0000000000586598 in ExecProcNode (node=0x7f4944419980) at
execProcnode.c:456
#15 0x00000000005968c5 in MultiExecHash (node=0x7f49444190e0) at
nodeHash.c:101
#16 0x000000000059729b in ExecHashJoin (node=0x7f49444168f0) at
nodeHashjoin.c:177
#17 0x0000000000586598 in ExecProcNode (node=0x7f49444168f0) at
execProcnode.c:456
#18 0x0000000000597876 in ExecHashJoin (node=0x7f49444157d0) at
nodeHashjoin.c:153
#19 0x0000000000586598 in ExecProcNode (node=0x7f49444157d0) at
execProcnode.c:456
#20 0x0000000000597876 in ExecHashJoin (node=0x7f49444146b0) at
nodeHashjoin.c:153
#21 0x0000000000586598 in ExecProcNode (node=0x7f49444146b0) at
execProcnode.c:456
#22 0x000000000059f2e9 in ExecSort (node=0x7f4944414440) at nodeSort.c:103
#23 0x0000000000586578 in ExecProcNode (node=0x7f4944414440) at
execProcnode.c:467
#24 0x000000000059b7f8 in ExecMergeJoin (node=0x1523a90) at
nodeMergejoin.c:682
#25 0x00000000005865a8 in ExecProcNode (node=0x1523a90) at
execProcnode.c:452
#26 0x000000000059f2e9 in ExecSort (node=0x1523820) at nodeSort.c:103
#27 0x0000000000586578 in ExecProcNode (node=0x1523820) at
execProcnode.c:467
#28 0x0000000000599a68 in ExecLimit (node=0x1523580) at nodeLimit.c:91
#29 0x00000000005864f8 in ExecProcNode (node=0x1523580) at
execProcnode.c:499
#30 0x0000000000583fe2 in ExecutePlan (dest=0x7f49444adf20,
direction=<optimized out>, numberTuples=0, sendTuples=1 '\001',
operation=CMD_SELECT,
    planstate=0x1523580, estate=0x1504520) at execMain.c:1395
#31 standard_ExecutorRun (queryDesc=0x14a3df0, direction=<optimized
out>, count=0) at execMain.c:303
#32 0x000000000065a5f7 in PortalRunSelect (portal=0x14afaf0,
forward=<optimized out>, count=0, dest=0x7f49444adf20) at pquery.c:944
#33 0x000000000065b968 in PortalRun (portal=0x14afaf0,
count=9223372036854775807, isTopLevel=1 '\001', dest=0x7f49444adf20,
altdest=0x7f49444adf20,
    completionTag=0x7fff393267f0 "") at pquery.c:788
#34 0x0000000000657cb3 in exec_simple_query (
    query_string=0x143fec0 "SELECT ST_AsGeoJson(geometry) AS
jsongeometry, (v_parcely_g.id) AS id, (v_parcely_g.katuze_kod::text ||
COALESCE(zdpaze_kod::te
xt, druh_cislovani_par::text, '0')::text ||
LPAD(kmenove_cislo_par::text,"...) at postgres.c:1046
#35 PostgresMain (argc=<optimized out>, argv=<optimized out>,
dbname=0x138c9b0 "sokolov", username=<optimized out>) at postgres.c:3959
#36 0x0000000000616f48 in BackendRun (port=0x137f870) at postmaster.c:3614
#37 BackendStartup (port=0x137f870) at postmaster.c:3304
#38 0x00000000006175d6 in ServerLoop () at postmaster.c:1367
#39 0x0000000000617ffc in PostmasterMain (argc=5, argv=<optimized out>)
at postmaster.c:1127
#40 0x00000000005b77ce in main (argc=5, argv=0x1360890) at main.c:199

Query:

SELECT ST_AsGeoJson(geometry) AS jsongeometry, (v_parcely_g.id) AS id,
(v_parcely_g.katuze_kod::text || COALESCE(zdpaze_kod::text,
druh_cislovani_par::text, '0')::text || LPAD(kmenove_cislo_par::text, 5,
'0') || LPAD(COALESCE(poddeleni_cisla_par,'0')::text, 3, '0') ||
COALESCE(dil_parcely,'0') ) AS vita, druh_cislovani_par,
kmenove_cislo_par, poddeleni_cisla_par, vymera_parcely, d_pozemku,
zp_vyuziti_poz, oprav_subjekty, pocet_vlastniku FROM v_parcely_g WHERE 
(ST_Intersects (geometry, GeomFromText('POINT(-867975.59044434
-1014786.6774316)', (select ST_SRID(geometry) from v_parcely_g where
ST_SRID(geometry) is not null LIMIT 1)))) ORDER BY druh_cislovani_par
ASC, kmenove_cislo_par ASC, poddeleni_cisla_par ASC limit 1;

Note: there is postgis 2.0 installed in that db as well and we did a soft-upgrade from it.

Versions:

postgresql - 9.3.4 (gentoo ebuild)
postgis - 2.1.1 (gentoo ebuild), but tried 2.1.0 as well with the same result

[pramsey]

You're going to want to bisect your input data to isolate the particular input geometry pair that is causing the crash, and then attach that pair of geometries to the ticket so others can reproduce the crash. The stack shows where the crash happened, but provides no clues to why. Only the input geometries can do that. Thanks!

[lefty]

We figured out, that it was caused by some deprecated functions left in the db by postgis2.0. Running legacy.sql fixed it. (Some error message instead of the crash would be helpful, however...)

[robe]

lefty,

Thanks for the feedback. I'm thinking its the same issue in this ticket too #2709

That also uses a deprecated GeomFromText.

I think we have on the ticket to make our legacy.sql scripts not version dependent. The main issue is that people don't know they need to reinstall if they upgrade to a new minor since the 2.0/2.1 whatever is embedded in the script.