ST_DumpPoints crash

[strk]

From garden test:

SELECT ST_DumpPoints(foo1.the_geom) As result
FROM ((SELECT ST_GeomFromText('POINT EMPTY',4326) As the_geom
UNION ALL SELECT ST_GeomFromText('MULTIPOINT EMPTY',4326) As the_geom
UNION ALL SELECT ST_GeomFromText('MULTIPOLYGON EMPTY',4326) As the_geom
UNION ALL SELECT ST_GeomFromText('LINESTRING EMPTY',4326) As the_geom
UNION ALL SELECT ST_GeomFromText('MULTILINESTRING EMPTY',4326) As the_geom ) ) As foo1 LIMIT 3;

Crashes the backend. Dunno which versions are affected, is to be tested.

[strk]

Simpler form:

SELECT ST_DumpPoints('POINT EMPTY'::geometry)

2.1.2 seems to be also affected

[strk]

I confirm 2.1.2 is affected

[pramsey]

Doesn't take a fancy query to do it either

select st_dumppoints('POLYGON EMPTY'::geometry);

[robe]

hmm weird. I'm pretty sure I tested those with 2.1.2 garden check. I don't think I got any crashes. I'll check again.

[robe]

Just tried on my 2.1.2 windows install

POSTGIS="2.1.2 r12389" GEOS="3.4.2-CAPI-1.8.2 r3924" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" TOPOLOGY RASTER

PostgreSQL 9.3.4, compiled by Visual C++ build 1600, 64-bit

neither crash

SELECT ST_DumpPoints('POINT EMPTY'::geometry);
SELECT st_dumppoints('POLYGON EMPTY'::geometry);

They just returns no records. This was the regression I mentioned (at least with POINT EMPTY between 2.0 and 2.1 though I recall POLYGON EMPTY returning the same non-answer)

[robe]

for the record seems to only be an issue with cassert enabled so production users are not likely to be affected by this.

[pramsey]

Fixed in trunk at r12430 and 2.1 branch at r12431