[postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?

[Magnus Hagander]

On Tue, Mar 8, 2011 at 10:16, Magnus Hagander <magnus at hagander.net> wrote:
> On Mon, Feb 28, 2011 at 16:35, Mark Cave-Ayland
> <mark.cave-ayland at siriusit.co.uk> wrote:
>> On 28/02/11 15:18, Magnus Hagander wrote:
>>
>>> Hi!
>>>
>>> Running the following query locks up postgis completely (in
>>> geos::algorithm::RobustDeterminant):
>>>
>>> SELECT st_intersects(somegeometry,
>>>
>>> '0103000020E61000000100000005000000737979F3DDCC2CC0F92154F9E7534540000000000000F07F000000000000F07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540'::geometry)
>>>
>>> I believe this is because there are infinite values in that geometry:
>>>
>>> # select
>>> ST_AsText('0103000020E61000000100000005000000737979F3DDCC2CC0F92154F9E7534540000000000000F07F000000000000F07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540'::geometry);
>>>
>>>   st_astext
>>>
>>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>  POLYGON((-14.4001308522972 42.6555167828373,inf inf,-85.9726317957995
>>> 82.0924680617579,42.5223944076352 43.6054577711015,-14.4001308522972
>>> 42.6555167828373))
>>> (1 row)
>>>
>>>
>>> ISTM that this should either be rejected as an invalid geometry, or at
>>> least not hang....
>>
>> Hi Magnus,
>>
>> Hmmmm - I can definitely reproduce this on trunk with GEOS 3.2 series. The
>> backtrace from inside GEOS looks like this:
>
> Since nobody appears to be too interested in producing a quick fix in
> geos, attached is a patch that puts in an *ugly* workaround in
> PostGIS, that simply rejects the infinite values higher up in the
> stack. I don't consider this a long-term fix, but it at least causes
> an error instead of getting stuck in an infinite loop that can only be
> terminated with kill -9... So pending a solution in geos, I would
> suggest this workaround (or something better located written by
> someone who actually know the postgis code better than me) be put in.
> The way it is now, any application that allows the user to specify
> input that could generate such a geometry could trivially
> denial-of-service any postgis site...

My customer has now been running with this patch in full productoin
for a couple of weeks, and reports that it has solved the problem for
them, with no ill effects.

Even if there is a solution eventually put down in the underlying
libraries, I believe this patch should be in PostGIS. For one, it's
going to take a while for the downstream fixes to trickle into all
distributions. And if/when they *are* fixed, the overhead will be
basically zero overhead.

And it *is* protecting against a boundary condition that basically
requires a restart of the whole database system - so I still claim
it's a bug in PostGIS *as well* in that case. So having thought some
more about it, it's actually not ugly imho :D

Anyway.

I humbly request that this patch - or equivalent functionality - be
applied to PostGIS both trunk and the branch for the next 1.5.x
release (assuming there is one).


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/