Segfault on ST_Intersection

[andrepl]

I'm receiving a segfault performing st_intersects on the 2 geometries included in the attached file.

[andrepl]

geometries which segfault st_intersects

[robe]

andrepl,

This isn't crashing for me on my PostGIS 2.0.1 nor PostGIS 2.1.0 instances.

I ran:

select st_intersects(g,g2) from reduce;

and returned true.

Can you please provide the output of the following query:

select version() || ' ' || postgis_full_version();

It's also possible that the geometry is malformed in the database but fixes itself when it goes thru the output process. I've had a case like that happen to me.

To test, you can reload the dump you have here into a new database and see if it crashes.

[andrepl]

Apologies, I meant to write ST_Intersection, not ST_Intersects. I updated the title of the ticket but I'm not sure if I can change the description...

running "select st_intersection(g,g2) from reduce" segfaults for me with this setup:

PostgreSQL 9.1.4 on x86_64-unknown-linux-gnu, compiled by gcc-4.4.real (Debian 4.4.5-8) 4.4.5, 64-bit POSTGIS="2.0.2SVN r10189" GEOS="3.3.5-CAPI-1.7.5" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.1, released 2012/05/15" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER

[robe]

Great always good to be able to reproduce the problem. It segfaults for me under both my 64-bit and 32-bit PostgreQL 9.1 PostGIS 2.0.1 and 2.1.0SVN installs.

[pramsey]

This crashes for me in GEOS 3.3.5 and 3.3.4 but works in 3.3.2.

[robe]

I was running 3.4.0dev so add that to the list to fix.

[strk]

Confirmed. See ​http://trac.osgeo.org/geos/ticket/586

[strk]

It's fixed in GEOS-3.3 branch (to become 3.3.6). Out of curiosity: are you running robustness tests ? I ask because the linear geometry is extremely scratchy, can't be any real physical feature, is it ?

[andrepl]

excellent news on the fix. The data is a series of real GPS readings.

[robe]

strk what about 3.4? Same issue there too I think.

[strk]

Robe, see the geos ticket for geos-related questions (both 3.3 and 3.4 were affected and both were fixed).

andrepl, weird tracks come out of those GPS:

I didn't try but I suspect that multiline might have other problems with other operations, worth stress-testing

This ticket will be closed as soon as GEOS-3.3.6 is out

[andrepl]

The wierd tracks are caused by the gps 'drifting' while the device is stationary. we pass the data through a douglas-peucker algorithm and that's the result... it's not pretty, and has been a real hassle to fully filter out while still getting accurate tracks.

[robe]

strk -- I have bad news for you -- my GEOS regress tests are failing (at least on my local pc where they all used to pass). It something like 30 failures out of those 3000 someodd xmltests. I think this is a new development. I'll try to narrow it down a bit more.

[strk]

Not only GEOS-3.3.6 was released, but up to GEOS-3.3.9, and GEOS 3.4.2. Can anyone still reproduce this ? Reopen if so.