ST_GeomFromWKB crashes PostgreSQL server

[dbaston]

Repeated attempts (about 3) to create a geometry from what may be an invalid WKB cause server to crash. Running on Windows 7, 64-bit.

SELECT ST_GeomFromWKB($$0104000020E61000000100000001010000008812F4177AE557C040745E6397943D40$$::bytea)

"POSTGIS="2.0.1 r9979" 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" TOPOLOGY RASTER"

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

[robe]

SELECT ST_GeomFromWKB('0104000020E61000000100000001010000008812F4177AE557C040745E6397943D40'::bytea) 

Crashes on my 9.2.4 windows 2008 x64 on my PostGIS 2.1.0beta2 as well, I have to check on my PostgreSQL 9.3 beta 64bit beta install, but I suspect its fine on that.

POSTGIS="2.1.0beta2 r11441" GEOS="3.4.0dev-CAPI-1.8.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 PostgreSQL 9.2.4, compiled by Visual C++ build 1600, 64-bit

I suspect its how we are throwing errors from c code or something about how the PostgreSQL 9.2 VC builds are compiled.

Try changing your function definition to this:

CREATE OR REPLACE FUNCTION st_geomfromwkb(bytea)
  RETURNS geometry AS
'$libdir/postgis-2.0', 'LWGEOM_from_WKB'
  LANGUAGE c STRICT
  COST 1;

Essentially taking out the IMMUTABLE from the definition. That fixes it for me.

I think this is the same issue as #2185

Which I'm still hunting down the cause.

[robe]

postgres logs just have:

2013-05-16 07:11:29 EDT LOG:  server process (PID 4384) was terminated by exception 0xC0000409

The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.

So I suspect maybe removing the IMMUTABLE prevents it from being cached and for some reason even though input is completely invalid its trying to cache it when IMMUTABLE is enabled destabilizing shared memory

[robe]

On closer inspection — I think its something wrong with the way PostGIS parser is throwing errors (which for whatever reason only PostgreSQL 9.2x64-bit is sensitive to).

The reason I say this is that the same function for geography which is defined in exactly the same way works just fine on my 9.2 64-bit 2.1.0beta2 and just throws the:

SELECT st_geogfromwkb('0104000020E61000000100000001010000008812F4177AE557C040745E6397943D40'::bytea);

ERROR:  Invalid endian flag value encountered.

regardless how many times I run it.

It too is defined with immutable strict

[robe]

What the frig?

SELECT st_geomfromewkb('0104000020E61000000100000001010000008812F4177AE557C040745E6397943D40'::bytea);

Doesn't crash and on closer inspection st_geomfromewkb uses the C function? LWGEOMFromWKB which directly calls lwgeom_from_wkb: ​http://postgis.net/docs/doxygen/2.1/d0/d92/lwin__wkb_8c_source.html#l00724

While The bad ST_GeomFromWKB uses: the C function LWGEOM_from_WKB which calls LWGEOMFromWKB ​http://www.postgis.net/docs/doxygen/2.1/da/d94/lwgeom__ogc_8c_source.html#l00790 and the result check seems to be doing nothing as result is always NULL. So what the hell is that doing?

That aside why isn't this just directly calling lwgeom_from_wkb like the good function is?

[robe]

fixed for 2.1 branch at r11473 (just skipping the intermediary call to LWGEOM and going straight to lwgeom)

[robe]

backported to 2.0 at r11475 (and minor comment refinement in 2.1 at r11474 )