Opened 8 months ago

Closed 8 months ago

#5621 closed defect (fixed)

LINESTRING EMPTY crashes nested ST_PointOnSurface and ST_Collect

Reported by: Wenjing Owned by: pramsey
Priority: critical Milestone: PostGIS GEOS
Component: postgis Version: 3.4.x
Keywords: Cc:

Description

LINESTRING EMPTY crashes nested ST_PointOnSurface and ST_Collect. I found and reported the same issue also in DuckDB: https://github.com/duckdb/duckdb_spatial/issues/195

SELECT ST_PointOnSurface(ST_Collect([ST_GeomFromText('LINESTRING(0 0, 1 1)'), ST_GeomFromText('LINESTRING EMPTY')]))
--Segmentation fault (core dumped)

Here is the stack information:

#0  0x00007f05988a9848 in geos::algorithm::InteriorPointLine::add(geos::geom::Coordinate const&) ()
   from /usr/local/lib/libgeos.so.3.13.0
#1  0x00007f05988a993d in geos::algorithm::InteriorPointLine::addInterior(geos::geom::CoordinateSequence const*) ()
   from /usr/local/lib/libgeos.so.3.13.0
#2  0x00007f05988a99d8 in geos::algorithm::InteriorPointLine::addInterior(geos::geom::Geometry const*) ()
   from /usr/local/lib/libgeos.so.3.13.0
#3  0x00007f05988a9beb in geos::algorithm::InteriorPointLine::InteriorPointLine(geos::geom::Geometry const*) ()
   from /usr/local/lib/libgeos.so.3.13.0
#4  0x00007f05989044b5 in geos::geom::Geometry::getInteriorPoint() const ()
   from /usr/local/lib/libgeos.so.3.13.0
#5  0x00007f05990808af in GEOSPointOnSurface_r ()
   from /usr/local/lib/libgeos_c.so.1
#6  0x00007f05993d8649 in lwgeom_pointonsurface (geom=0x560078958718)
    at lwgeom_geos.c:1025
#7  0x00007f059930ab5c in pointonsurface (fcinfo=0x56007895ca10)
    at lwgeom_geos.c:1496
#8  0x000056007653aed0 in ExecInterpExpr ()
#9  0x000056007662a4a4 in evaluate_expr ()
#10 0x000056007662a6f1 in simplify_function ()
#11 0x000056007662b68d in eval_const_expressions_mutator ()
#12 0x00005600765a6881 in expression_tree_mutator_impl ()
#13 0x00005600765a6d5c in expression_tree_mutator_impl ()
#14 0x000056007662c5e3 in eval_const_expressions ()
#15 0x0000560076612418 in preprocess_expression ()
#16 0x0000560076619832 in subquery_planner ()
#17 0x000056007661a023 in standard_planner ()
#18 0x00005600766d721f in pg_plan_query ()
#19 0x00005600766d7301 in pg_plan_queries ()
#20 0x00005600766d75e0 in exec_simple_query ()
#21 0x00005600766d9a05 in PostgresMain ()
#22 0x0000560076653bce in ServerLoop ()
#23 0x0000560076654b1c in PostmasterMain ()
#24 0x00005600763a6bb1 in main ()

Version:

                postgis_full_version                                                                                                                    
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 POSTGIS="3.5.0dev 3.4.0rc1-800-g96e265b7a" [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"

Change History (3)

comment:1 by robe, 8 months ago

Milestone: PostGIS 3.4.2PostGIS GEOS

I was hoping this issue would be fixed by https://github.com/libgeos/geos/issues/976

but guess it's separate. I'll report there.

I don't want to make the same change as Duckdb, as I think there are some people that expect to get an empty geometry in their collection if they put one in.

comment:3 by robe, 8 months ago

Resolution: fixed
Status: newclosed

This is now fixed in geos and will be available in upcoming GEOS 3.12.2, 3.11.4, and 3.10.7

Note: See TracTickets for help on using tickets.