Opened 12 months ago
Closed 12 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 , 12 months ago
Milestone: | PostGIS 3.4.2 → PostGIS GEOS |
---|
comment:3 by , 12 months ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
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.