Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#2332 closed defect (fixed)

ST_GeomFromWKB crashes PostgreSQL server

Reported by: dbaston Owned by: robe
Priority: blocker Milestone: PostGIS 2.0.4
Component: postgis Version: 2.0.x
Keywords: history Cc:


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"

Change History (7)

comment:1 by robe, 11 years ago

Milestone: PostGIS 2.1.0PostGIS 2.0.4
Priority: mediumblocker
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'
  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.

comment:2 by robe, 11 years ago

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

comment:3 by robe, 11 years ago

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

comment:4 by robe, 11 years ago

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:

While The bad ST_GeomFromWKB uses: the C function LWGEOM_from_WKB which calls LWGEOMFromWKB 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?

comment:5 by robe, 11 years ago

Owner: changed from pramsey to robe

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

comment:6 by robe, 11 years ago

Resolution: fixed
Status: newclosed

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

comment:7 by robe, 10 years ago

Keywords: history added
Note: See TracTickets for help on using tickets.