This geometry causes buffer(?, 0) to crash the PostGresql server

[robe]

This was submitted to PostGIS -- and we have confirmed this to be an issue in 3.0.3 and 3.1.0 SVN of GEOS with newer installs of PostGIS and believe its a GEOS bug and not a PostGIS one. Refer to ​http://code.google.com/p/postgis/issues/detail?id=81

What steps will reproduce the problem?

1. Run the attached script

What is the expected output? What do you see instead?

server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
connection to server was lost

What version of the product are you using? On what operating system?

psql 8.3.5
postgis_version: 1.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
postgis_geos_version: 3.0.1-CAPI-1.4.2
Fedora 10

Please provide any additional information below.

The following is written to the log file:

bufferOriginalPrecision failed (TopologyException: unable to assign hole to a shell), trying with reduced precision recomputing with precision scale factor = 1e+09
Scaler: offsetX,Y: 0,0 scaleFactor: 1e+09
 dstahlke svdev [local] SELECT:
../../source/headers/geos/noding/SegmentString.h:175: void geos::noding::SegmentString::testInvariant() const: Assertion `pts->size() > 1' failed.
LOG:  server process (PID 863) was terminated by signal 6: Aborted
LOG:  terminating any other active server processes
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted; last known up at 2008-12-05 14:16:19 AKST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/3C5BC340
LOG:  redo is not required
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started

[pramsey]

OK, I can reproduce the crash here. The problem is that the fifth component of the MULTIPOLYGON is a zero-area (within floating point tolerance) square. If I re-build the multipolygon without that element, the crash goes away. Here's what I did...

 pramsey=# create table foo as select geometryn(geom,generate_series(1,6)) from badbuffer;
 SELECT 
 pramsey=# select count(*) from foo;
 count 
 -------
     6
 (1 row)
 pramsey=# delete from foo where area(geometryn) = 0;
 DELETE 1
 pramsey=# create table foo2 as select collect(geometryn) as geom from foo;
 SELECT
 pramsey=# select count(*) from foo2;
 count 
 -------
      1
 (1 row)
 pramsey=# select geometrytype(geom) from foo2;
  geometrytype  
 --------------
  MULTIPOLYGON
 (1 row)
 pramsey=# select isvalid(buffer(geom,0)) from foo2;
  isvalid 
 ---------
  t
 (1 row)

So the work-around is there, if you need it, and we know pretty precisely where the problem is to go and fix it.

[strk]

Confirmed, can reproduce with a GEOS XML test. Working on it.

[strk]

Fixed as of revision 2481.

[strk]

Note: the input multipolygon is invalid: NOTICE: Self-intersection at or near point -164.805 63.0918

That said, I don't think it is sane to put it into an XML tester as we can't really pretend the non-segfaulting result is the correct one (and it isn't, in that it trims out the offending polygon)

[pramsey]

Right, the reason people are running buffer(,0) is to "clean" invalid polygons. What we need is to start building an API specifically for that purpose that expects, nay, welcomes invalidity.

[strk]

XML test file

[strk]

SQL file with input/output geoms

[strk]

Not sure the result I'm seeing we can accept as an "expected" cleanup output.

I attach an XML tester (expecting empty geom, just for fun) and an SQL file that creates a bug219_xml table with fields 'a' as input geometry and 'obtained' as the result of buffer(0).

Martin, your thoughts on this ? Is it sane to use Buffer(0) to cleanup geoms, and is what you get on the attached geometry an expected cleanup ?