[postgis-devel] ST_MaximumInscribedCircle madness

[Regina Obe]

I have ticketed - https://github.com/libgeos/geos/issues/875

 

 

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Martin Davis
Sent: Thursday, April 20, 2023 8:45 PM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] ST_MaximumInscribedCircle madness

 

There's only one main loop, so an interrupt check can go there:

 

https://github.com/libgeos/geos/blob/main/src/algorithm/construct/MaximumInscribedCircle.cpp#L187

 

On Thu, Apr 20, 2023 at 5:33 PM Paul Ramsey <pramsey at cleverelephant.ca <mailto:pramsey at cleverelephant.ca> > wrote:

One thing we can do is find a reasonable place in the loop to put an interrupt check. Where does it spend its time when it’s in this state?





On Apr 20, 2023, at 5:31 PM, Martin Davis <mtnclimb at gmail.com <mailto:mtnclimb at gmail.com> > wrote:

 

That geometry is indeed a simple rectangle, but it's very, very, very narrow.   This is causing the interative algorithm used in MaximmumInscribedCircle to essentially hunt forever trying to find a point which lies inside the polygon.

 

Of course it would be nice to detect this situation and terminate faster, either with a point which lies actually lies outside the rectangle, or some other return value.  This will require some thought.

 

On Thu, Apr 20, 2023 at 2:38 PM Rémi Cura <remi.cura at gmail.com <mailto:remi.cura at gmail.com> > wrote:

Hello dear Postgis devs!

I have a strange case to submit to you.

In a nutshell, trying to compute 

```SQL
SELECT ST_MaximumInscribedCircle( 'POLYGON ((59.3 100.00000000000001, 99.7 100.00000000000001, 99.7 100, 59.3 100, 59.3 100.00000000000001))') ;
```

causes it to run for many minutes until it eventually errors.

Worst, running this kind of computing on 12M geoms in parallel x6 created a postgres **segfault** and crashed my server (16 cores, 64GB).

(many more geoms are making this function unhappy).


/!\ Once this query starts, it can't be stopped by `pg_cancel_backend(pid)` or even `pg_terminate_backend(pid)`

--> This is pretty dangerous in my opinion.

 

 

The geometry is simple, it is a rectangle.

I obtained it through other geometry operations

It must be some kind of precision issue, I'm wondering if there is some kind of infinite loop going on or something.

 

My full code is something like that:

```SQL
SELECT env, diff, ST_MaximumInscribedCircle(diff)
FROM CAST ('some_polygon'as text ) as g
    , ST_Envelope(g) as env
    , ST_MakeEnvelope(0,0,100,100) as bound
    , ST_Difference(env, bound) as diff;
```

 

Not creating a bug ticket as I don't know if I'm simply abusing the function / using it in a way it should not.

 

 

POSTGIS="3.1.7 aafe1ff" [EXTENSION] PGSQL="140" GEOS="3.9.1-CAPI-1.14.2" PROJ="8.0.1" GDAL="GDAL 3.4.3, released 2022/04/22" LIBXML="2.9.1" LIBJSON="0.15" LIBPROTOBUF="1.3.2" WAGYU="0.5.0 (Internal)" RASTER

 

PostgreSQL 14.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-12), 64-bit

_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/postgis-devel

_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/postgis-devel

 

_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20230420/3562effe/attachment-0001.htm>