Garden Crash test failed: ST_Snap

[robe]

I generated a garden test using 2.0 garden and testing with 2.1 and sadly the thing kicked the bucket.

This crashes the server service: on my

POSTGIS="2.1.0rc3 r11766" GEOS="3.5.0dev-CAPI-1.9.0 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER

SELECT ST_Snap(foo1.the_geom, foo2.the_geom, 0.5) As result, ST_AsText(foo1.the_geom) As ref1_geom, ST_AsText(foo2.the_geom) As ref2_geom
	FROM ((SELECT geom  As the_geom
FROM (VALUES ( ST_GeomFromEWKT('SRID=4326;POLYGONM((-71.1319 42.2503 1,-71.132 42.2502 3,-71.1323 42.2504 -2,-71.1322 42.2505 1,-71.1319 42.2503 0))') ),
	( ST_GeomFromEWKT('SRID=4326;POLYGONM((-71.1319 42.2512 0,-71.1318 42.2511 20,-71.1317 42.2511 -20,-71.1317 42.251 5,-71.1317 42.2509 4,-71.132 42.2511 6,-71.1319 42.2512 30))') )
		)	As g(geom))) As foo1 CROSS JOIN ((SELECT ST_Collect(geom)  As the_geom
		FROM (VALUES ( ST_GeomFromEWKT('SRID=4326;MULTIPOLYGON(((-71.0821 42.3036 2,-71.0822 42.3036 2,-71.082 42.3038 2,-71.0819 42.3037 2,-71.0821 42.3036 2)))') ),
	( ST_GeomFromEWKT('SRID=4326;POLYGON((-71.1261 42.2703 1,-71.1257 42.2703 1,-71.1257 42.2701 1,-71.126 42.2701 1,-71.1261 42.2702 1,-71.1261 42.2703 1))') ) ) As g(geom) CROSS JOIN generate_series(1,3) As i GROUP BY i )) As foo2 LIMIT 2;

I suspect this may be a GEOS bug because my parallel:

POSTGIS="2.0.3 r11132" GEOS="3.5.0dev-CAPI-1.9.0 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER

also crashes. I'll try to swap out the GEOS to see if 2.0.3 still fails with older GEOS.

[robe]

Forgot to mention (just in case no one else is having the issue)

PostgreSQL 9.2.4, compiled by Visual C++ build 1600, 32-bit

32-bit PostgreSQL running on 64bit windows 7

[robe]

I have a strong feeling this is a geos bug in 3.4.0. I tried this on my

POSTGIS="2.0.3 r11132" GEOS="3.3.8-CAPI-1.7.8" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, released 2012/10/08 GDAL_DATA not found" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER

This is a windows 7 32-bit server and it does not crash.

[robe]

I know how pramsey hats deciphering monkey generated sql so I have reduced it to the offending record.

SELECT ST_Snap('POLYGON Z ((-71.1319 42.2512 0,-71.1318 42.2511 20,-71.1317 42.2511 -20,-71.1317 42.251 5,-71.1317 42.2509 4,-71.132 42.2511 6,-71.1319 42.2512 30))'::geometry, 'GEOMETRYCOLLECTION Z (MULTIPOLYGON Z (((-71.0821 42.3036 2,-71.0822 42.3036 2,-71.082 42.3038 2,-71.0819 42.3037 2,-71.0821 42.3036 2))),POLYGON Z ((-71.1261 42.2703 1,-71.1257 42.2703 1,-71.1257 42.2701 1,-71.126 42.2701 1,-71.1261 42.2702 1,-71.1261 42.2703 1)))'::geometry, 0.5)

In fact I think we have a ticket in GEOS for this or something similar. I'll have to dig it up.

[robe]

The geos ticket I was thinking of was ​http://trac.osgeo.org/geos/ticket/604 but that one was for Delaunay.

I can't find an open GEOS ticket for ST_Snap. strk or someone who is running 3.4 branch can you confirm this crashes on your OS too (none windows) and if so we should probably add as a GEOS 3.4 issue.

[strk]

LIMIT 1 OFFSET 2 still crashes, please reduce the input as much as you can to make fixing this easier. The GEOS ticket is ​http://trac.osgeo.org/geos/ticket/649 (you just filed it)

[strk]

Interesting enough isolating the input and calling it in a separate statement does NOT trigger a segfault. So the problem must be in some memory messing piece of code. It's probably postgis only.

[strk]

The isolated input:

A: 0103000060E61000000100000005000000EA95B20C71C851C02B1895D409204540000000000000F03F9CC420B072C851C0C7BAB88D062045400000000000000840B1506B9A77C851C08E75711B0D20454000000000000000C0FF21FDF675C851C0F2D24D6210204540000000000000F03FEA95B20C71C851C02B1895D4092045400000000000000000
B: 01070000A0E610000002000000010600008001000000010300008001000000050000001AC05B2041C551C06688635DDC2645400000000000000040CCEEC9C342C551C06688635DDC26454000000000000000406891ED7C3FC551C02D431CEBE22645400000000000000040B7627FD93DC551C0C9E53FA4DF26454000000000000000401AC05B2041C551C06688635DDC264540000000000000004001030000800100000006000000A301BC0512C851C0ED0DBE3099224540000000000000F03FDC4603780BC851C0ED0DBE3099224540000000000000F03FDC4603780BC851C0265305A392224540000000000000F03FF2D24D6210C851C0265305A392224540000000000000F03FA301BC0512C851C08AB0E1E995224540000000000000F03FA301BC0512C851C0ED0DBE3099224540000000000000F03F

[robe]

So why does it not fail in PostGIS under 3.3 and PostGIS 2.0.3, but does if I have GEOS 3.4 and PostGIS 2.0.3?

[strk]

I've spotted this into the logs:

 snap/LineStringSnapper.cpp:349: void geos::operation::overlay::snap::LineStringSnapper::snapSegments(geos::geom::CoordinateList&, const ConstVect&): Assertion `pf != 0.0' failed.

Reviewing the code actually seems to suggest there's a bug in GEOS, but for some reason I can't reproduce it with a geos-only input !?

Can you isolate a simple offending case ?

[strk]

My previous isolation was likely wrong, this one works:

select st_snap('POLYGON M ((-71.1319 42.2512 0,-71.1318 42.2511 20,-71.1317 42.2511 -20,-71.1317 42.251 5,-71.1317 42.2509 4,-71.132 42.2511 6,-71.1319 42.2512 30))', 'GEOMETRYCOLLECTION Z (MULTIPOLYGON Z (((-71.0821 42.3036 2,-71.0822 42.3036 2,-71.082 42.3038 2,-71.0819 42.3037 2,-71.0821 42.3036 2))),POLYGON Z ((-71.1261 42.2703 1,-71.1257 42.2703 1,-71.1257 42.2701 1,-71.126 42.2701 1,-71.1261 42.2702 1,-71.1261 42.2703 1)))', 0.5);

[strk]

Further simplification:

select st_snap('LINESTRING(-71.1317 42.2511,-71.1317 42.251,-71.1317 42.2509)', 'MULTIPOINT(-71.1261 42.2703,-71.1257 42.2703,-71.1261 42.2702)', 0.5);

[strk]

Bug fixed upstream. Will be shipped in 3.4.1 (shouldn't that be today robe?). Let's close once GEOS-3.4.1 is out. More gardens are very welcome.

[robe]

strk — I need to do one more full run. I'm thinking of releasing 3.4.1 over the weekend.

[robe]

forgot to close this one out pased after your changes in geos 3.4.1