A Crash bug occur in ST_PointOnSurface

[Wenjing]

The following statement crashes PostGIS:

SELECT ST_PointOnSurface(g)  FROM ST_GeomFromText('MULTIPOINT((0 0), EMPTY)') As g;

Here is stack information:

#0  geos::algorithm::InteriorPointPoint::add (this=0x7ffed776fe60, point=0x0)
    at /home/wendy/PostGIS/postgis-workshop-2020/geos/src/algorithm/InteriorPointPoint.cpp:69
#1  0x00007f62b0180f4a in geos::algorithm::InteriorPointPoint::add (this=0x7ffed776fe60, 
    geom=<optimized out>)
    at /home/wendy/PostGIS/postgis-workshop-2020/geos/src/algorithm/InteriorPointPoint.cpp:59
#2  0x00007f62b0180ff6 in geos::algorithm::InteriorPointPoint::InteriorPointPoint (
    this=<optimized out>, g=<optimized out>)
    at /home/wendy/PostGIS/postgis-workshop-2020/geos/src/algorithm/InteriorPointPoint.cpp:42
#3  0x00007f62b0197e85 in geos::geom::Geometry::getInteriorPoint (
    this=this@entry=0x556c1e75b880)
    at /home/wendy/PostGIS/postgis-workshop-2020/geos/src/geom/Geometry.cpp:189
#4  0x00007f62b089b0a8 in operator() (__closure=<optimized out>)
--Type <RET> for more, q to quit, c to continue without paging--
   gis-workshop-2020/geos/capi/geos_ts_c.cpp:1458
#5  execute<GEOSPointOnSurface_r(GEOSContextHandle_t, const geos::geom::Geometry*)::<lambda()> > (f=..., extHandle=0x556c1ea26be0)
    at /home/wendy/PostGIS/postgis-workshop-2020/geos/capi/geos_ts_c.cpp:408
#6  GEOSPointOnSurface_r (extHandle=0x556c1ea26be0, g1=0x556c1e75b880)
    at /home/wendy/PostGIS/postgis-workshop-2020/geos/capi/geos_ts_c.cpp:1457
#7  0x00007f62b09abb17 in lwgeom_pointonsurface (geom=<optimized out>)
    at lwgeom_geos.c:1074
#8  0x00007f62b08f8f80 in pointonsurface (fcinfo=0x556c1e6e8ef0) at lwgeom_geos.c:1535
#9  0x0000556c1d24a4f0 in ExecInterpExpr ()
#10 0x0000556c1d337c94 in evaluate_expr ()
#11 0x0000556c1d337ee1 in simplify_function ()
#12 0x0000556c1d338e7d in eval_const_expressions_mutator ()
#13 0x0000556c1d2b5a61 in expression_tree_mutator_impl ()
#14 0x0000556c1d2b5f04 in expression_tree_mutator_impl ()
#15 0x0000556c1d339de3 in eval_const_expressions ()
#16 0x0000556c1d31fcd8 in preprocess_expression ()
#17 0x0000556c1d327072 in subquery_planner ()
#18 0x0000556c1d327863 in standard_planner ()
#19 0x0000556c1d3e42bf in pg_plan_query ()
#20 0x0000556c1d3e43a1 in pg_plan_queries ()
#21 0x0000556c1d3e4680 in exec_simple_query ()
#22 0x0000556c1d3e6aae in PostgresMain ()
#23 0x0000556c1d36142e in ServerLoop ()
#24 0x0000556c1d36237c in PostmasterMain ()
#25 0x0000556c1d0b6cb1 in main ()

The version is the newest in GitHub: POSTGIS="3.5.0dev 3.4.0rc1-705-g5c3ec8392" [EXTENSION] PGSQL="170" GEOS="3.13.0dev-CAPI-1.18.0" PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=​https://cdn.proj.org USER_WRITABLE_DIRECTORY=/tmp/proj DATABASE_PATH=/usr/share/proj/proj.db" LIBXML="2.9.13"

[mdavis]

Reported in ​GEOS 976

[mdavis]

Fixed in GEOS by ​https://github.com/libgeos/geos/pull/977 (from 3.11 on).

[robe]

Strange is this a recent bug. I noticed berries that test gardentests which should have this have been crashing, but looked like a different issue or I am missing this particular kind of empty permutation.