Opened 4 years ago
Closed 4 years ago
#4731 closed defect (fixed)
Garden crash ST_WrapX with new GEOS 3.9 Overlay logic
| Reported by: | robe | Owned by: | pramsey |
|---|---|---|---|
| Priority: | blocker | Milestone: | PostGIS GEOS |
| Component: | postgis | Version: | master |
| Keywords: | Cc: |
Description
I'm guessing this has nothing to do with my GEOS 3.9 overlay switch turn on, but I ran my garden test after and it's crashing
SELECT ST_WrapX(foo1.the_geom, 20.1, 20.1) As result FROM ((SELECT ST_MakeLine(ST_SetSRID(ST_Point(i,j),4326),ST_SetSRID(ST_Point(j,i),4326)) As the_geom FROM (SELECT a*1.11111111 FROM generate_series(-10,50,10) As a) As i(i) CROSS JOIN generate_series(40,70, 15) As j WHERE NOT(i = j) ORDER BY i, i*j)) As foo1 LIMIT 10;
The reduced form
SELECT ST_WrapX('LINESTRING(-11.1111111 70,70 -11.1111111)'::geometry, 20.1,20.1);
Also crashes for me:
I'm running
PostgreSQL 13beta2 on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0, 64-bit POSTGIS="3.1.0dev 3.1.0alpha2-5-gdcfb1258c" [EXTENSION] PGSQL="130" GEOS="3.9.0-CAPI-1.14.0" SFCGAL="1.3.8" PROJ="6.2.1" GDAL="GDAL 3.0.2, released 2019/10/28" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" RASTER
Works fine in my PostGIS 3.0.1 so must be recent change
Change History (13)
comment:1 by , 4 years ago
comment:2 by , 4 years ago
aha I think I found the change
#26074 lwgeom_wrapx (lwgeom_in=lwgeom_in@entry=0x5beb690,
cutx=cutx@entry=20.100000000000001,
amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:190
#26075 0x000000006efcaba8 in ST_WrapX (fcinfo=0x80433a8)
at lwgeom_functions_basic.c:1105
#26076 0x00000000005ec5be in ExecInterpExpr (state=0x80432b8,
econtext=0x8043538, isnull=<optimized out>) at execExprInterp.c:699
#26077 0x00000000006bdc81 in ExecEvalExprSwitchContext (isNull=0x4d6ea1c,
econtext=<optimized out>, state=0x80432b8)
commit f0822be70/git change of file postgis/lwgeom_functions_basic.c
ticket #4698
comment:3 by , 4 years ago
| Owner: | changed from to |
|---|
comment:4 by , 4 years ago
| Owner: | changed from to |
|---|
aha I think I found the change
commit f0822be70/git change of file postgis/lwgeom_functions_basic.c
ticket #4698
Is this a bisection or just a hunch? Because I don't see how adding a precision parameter to ST_AsEWKT might have broken ST_WrapX, even if the declaration lives in the same file.
Anyway, I've just tested with master and "normal" GEOS and it works:
template_postgis=# Select postgis_full_version();
postgis_full_version
-----------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------
POSTGIS="3.1.0dev c35256b1d" [EXTENSION] PGSQL="120" GEOS="3.9.0dev-CAPI-1.14.0" PROJ="6.3.2" GDAL="GDAL 3.0.4, released 202
0/01/28" LIBXML="2.9.10" LIBJSON="0.14" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" (core procs from "3.1.0dev 81b9af77b" ne
ed upgrade) TOPOLOGY RASTER (raster procs from "3.1.0dev 81b9af77b" need upgrade)
(1 row)
Time: 14.172 ms
template_postgis=# SELECT ST_WrapX('LINESTRING(-11.1111111 70,70 -11.1111111)'::geometry, 20.1,20.1);
st_wrapx
-----------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------
0105000000020000000102000000020000003DC159A54FFA214000000000008051409A99999999194440B5D6BC4FFA6443400102000000020000009A9999
9999193440B5D6BC4FFA6443400000000000805140F771D98DE33826C0
(1 row)
Time: 1.271 ms
Are you sure this isn't an issue with the new overlay?
comment:5 by , 4 years ago
no I realized after I blamed you it is unlike to be that 
I didn't think ST_WrapX uses GEOS, but I'll test next without the overlay — sorry for the blame
comment:6 by , 4 years ago
Confirmed works with my non-overlay GEOS version so guess GEOS is the culprit it seems.
comment:7 by , 4 years ago
| Owner: | changed from to |
|---|
comment:8 by , 4 years ago
| Milestone: | PostGIS 3.1.0 → PostGIS GEOS |
|---|---|
| Summary: | Garden crash ST_WrapX → Garden crash ST_WrapX with new GEOS 3.9 Overlay logic |
comment:9 by , 4 years ago
The core of this is a change in behavior. This result comes from overlayng:
50
select st_astext(st_difference('LINESTRING(-11.1111111 70,70 -11.1111111)'::geometry, 'LINESTRING (20.1 90, 20.1 -90)'::geometry));
st_astext
-----------------------------------------------------------
LINESTRING(-11.1111111 70,20.1 38.7888889,70 -11.1111111)
(1 row)
The lwgeom_split_wrapx function expects a split (which under the covers is a difference of a line away from an input) to return a collection, which it then iterates on. Instead we hand it a unitary object… which it then goes and tries to split again. Hence the infinite recursion. We need probably the old behaviour back, so that a GEOS 3.9 install doesn't break older software.
comment:11 by , 4 years ago
FWIW now that I realized by cunit was broken and fixed it, the wrap x cunit fails.
Suite: wrapx
Test: test_lwgeom_wrapx ...FAILED
1. cu_wrapx.c:85 - ASSERT_STRING_EQUAL
* Expected: MULTILINESTRING((0 0,8 0),(-2 0,0 0))
* Obtained: MULTILINESTRING((-2 0,0 0),(0 0,8 0))
2. cu_wrapx.c:123 - ASSERT_STRING_EQUAL
* Expected: GEOMETRYCOLLECTION(MULTIPOLYGON(((22 0,20 0,20 10,22 10,22 4,22 2,22 0)),((2 10,10 10,10 0,2 0,2 2,4 2,4 4,2 4,2 10))),MULTIPOLYGON(((22 11,20 11,20 21,22 21,22 15,22 13,22 11)),((2 21,10 21,10 11,2 11,2 13,4 13,4 15,2 15,2 21))))
* Obtained: GEOMETRYCOLLECTION(MULTIPOLYGON(((20 0,20 10,22 10,22 4,22 2,22 0,20 0)),((2 0,2 2,4 2,4 4,2 4,2 10,10 10,10 0,2 0))),MULTIPOLYGON(((20 11,20 21,22 21,22 15,22 13,22 11,20 11)),((2 11,2 13,4 13,4 15,2 15,2 21,10 21,10 11,2 11))))
Though this might be a order of polygon difference issue fixable with normalize.
comment:12 by , 4 years ago
With the latest GEOS master, this should be gone, because we are now splitting things the "old fashioned way" again. Probably this function on the PostGIS side should have an iteration guard too though…
comment:13 by , 4 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
gdb seems to go on forever
#26014 lwgeom_wrapx (lwgeom_in=0x8073798, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26015 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x80737f0, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26016 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x80735c0) at lwgeom_wrapx.c:107 #26017 lwgeom_wrapx (lwgeom_in=0x80735c0, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26018 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x8073618, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26019 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x80733e8) at lwgeom_wrapx.c:107 #26020 lwgeom_wrapx (lwgeom_in=0x80733e8, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26021 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x8073440, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26022 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x8073210) at lwgeom_wrapx.c:107 #26023 lwgeom_wrapx (lwgeom_in=0x8073210, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26024 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x8073268, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26025 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5bed478) at lwgeom_wrapx.c:107 #26026 lwgeom_wrapx (lwgeom_in=0x5bed478, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26027 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5bed4d0, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26028 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5bed2a0) at lwgeom_wrapx.c:107 #26029 lwgeom_wrapx (lwgeom_in=0x5bed2a0, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26030 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5bed2f8, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26031 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5bed0c8) at lwgeom_wrapx.c:107 #26032 lwgeom_wrapx (lwgeom_in=0x5bed0c8, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26033 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5bed120, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26034 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5becef0) at lwgeom_wrapx.c:107 #26035 lwgeom_wrapx (lwgeom_in=0x5becef0, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26036 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5becf48, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26037 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5becd18) at lwgeom_wrapx.c:107 #26038 lwgeom_wrapx (lwgeom_in=0x5becd18, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26039 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5becd70, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26040 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5becb40) at lwgeom_wrapx.c:107 #26041 lwgeom_wrapx (lwgeom_in=0x5becb40, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26042 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5becb98, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26043 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5bec968) at lwgeom_wrapx.c:107 #26044 lwgeom_wrapx (lwgeom_in=0x5bec968, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26045 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5bec9c0, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26046 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5bec790) at lwgeom_wrapx.c:107 #26047 lwgeom_wrapx (lwgeom_in=0x5bec790, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26048 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5bec7e8, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26049 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5bec5b8) at lwgeom_wrapx.c:107 #26050 lwgeom_wrapx (lwgeom_in=0x5bec5b8, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26051 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5bec610, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26052 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5bec3e0) at lwgeom_wrapx.c:107 #26053 lwgeom_wrapx (lwgeom_in=0x5bec3e0, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26054 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5bec438, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26055 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5bec208) at lwgeom_wrapx.c:107 #26056 lwgeom_wrapx (lwgeom_in=0x5bec208, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26057 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5bec260, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26058 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5bec030) at lwgeom_wrapx.c:107 #26059 lwgeom_wrapx (lwgeom_in=0x5bec030, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26060 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5bec088, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26061 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5bebe58) at lwgeom_wrapx.c:107 #26062 lwgeom_wrapx (lwgeom_in=0x5bebe58, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26063 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5bebeb0, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26064 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5bebc80) at lwgeom_wrapx.c:107 #26065 lwgeom_wrapx (lwgeom_in=0x5bebc80, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26066 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5bebcd8, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26067 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5bebaa8) at lwgeom_wrapx.c:107 #26068 lwgeom_wrapx (lwgeom_in=0x5bebaa8, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26069 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5bebb00, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26070 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5beb8d0) at lwgeom_wrapx.c:107 #26071 lwgeom_wrapx (lwgeom_in=0x5beb8d0, cutx=20.100000000000001, amount=20.100000000000001) at lwgeom_wrapx.c:190 #26072 0x000000006f06ae82 in lwcollection_wrapx (lwcoll_in=0x5beb928, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:138 #26073 0x000000006f06aa38 in lwgeom_split_wrapx (amount=20.100000000000001, cutx=20.100000000000001, geom_in=0x5beb690) at lwgeom_wrapx.c:107 #26074 lwgeom_wrapx (lwgeom_in=lwgeom_in@entry=0x5beb690, cutx=cutx@entry=20.100000000000001, amount=amount@entry=20.100000000000001) at lwgeom_wrapx.c:190 #26075 0x000000006efcaba8 in ST_WrapX (fcinfo=0x80433a8) at lwgeom_functions_basic.c:1105 #26076 0x00000000005ec5be in ExecInterpExpr (state=0x80432b8, econtext=0x8043538, isnull=<optimized out>) at execExprInterp.c:699 #26077 0x00000000006bdc81 in ExecEvalExprSwitchContext (isNull=0x4d6ea1c, econtext=<optimized out>, state=0x80432b8) at ../../../../src/include/executor/executor.h:313 #26078 evaluate_expr (expr=<optimized out>, result_type=result_type@entry=119675, result_typmod=result_typmod@entry=-1, result_collation=result_collation@entry=0) at clauses.c:4809 #26079 0x00000000006bf528 in evaluate_function (context=0x4d6eec0, func_tuple=0x7fb7948, funcvariadic=false, args=0x8071910, input_collid=0, result_collid=0, result_typmod=-1, result_type=119675, funcid=119849) at clauses.c:4340 #26080 simplify_function (funcid=119849, result_type=119675, result_typmod=-1, result_collid=result_collid@entry=0, input_collid=input_collid@entry=0, args_p=args_p@entry=0x4d6ec00, funcvariadic=funcvariadic@entry=false, process_args=process_args@entry=true, allow_non_const=allow_non_const@entry=true, context=context@entry=0x4d6eec0) at clauses.c:3970 #26081 0x00000000006be092 in eval_const_expressions_mutator (node=0x80711e0, context=0x4d6eec0) at clauses.c:2475 #26082 0x000000000065d574 in expression_tree_mutator ( node=node@entry=0x8071238, mutator=mutator@entry=0x6bdd20 <eval_const_expressions_mutator>, context=context@entry=0x4d6eec0) at nodeFuncs.c:3131 #26083 0x00000000006bdd72 in eval_const_expressions_mutator (node=0x8071238, context=0x4d6eec0) at clauses.c:3537 #26084 0x000000000065df55 in expression_tree_mutator ( node=node@entry=0x8071290, mutator=mutator@entry=0x6bdd20 <eval_const_expressions_mutator>, context=context@entry=0x4d6eec0) at nodeFuncs.c:3010 #26085 0x00000000006bdd72 in eval_const_expressions_mutator (node=0x8071290, context=context@entry=0x4d6eec0) at clauses.c:3537 #26086 0x00000000006bf394 in eval_const_expressions ( root=root@entry=0x8071398, node=<optimized out>) at clauses.c:2267 #26087 0x00000000006a2b18 in preprocess_expression ( root=root@entry=0x8071398, expr=<optimized out>, kind=kind@entry=1) at planner.c:1094 #26088 0x00000000006aa8f4 in subquery_planner (glob=glob@entry=0x5bbdf70, parse=<optimized out>, parse@entry=0x5bbe088, parent_root=parent_root@entry=0x0, hasRecursion=hasRecursion@entry=false, tuple_fraction=tuple_fraction@entry=0) at planner.c:771 #26089 0x00000000006ac2cf in standard_planner (parse=0x5bbe088, query_string=<optimized out>, cursorOptions=256, boundParams=<optimized out>) at planner.c:405 #26090 0x0000000000780eea in pg_plan_query (querytree=0x5bbe088, query_string=0x5bbcef0 "SELECT ST_WrapX('LINESTRING(-11.1111111 70,70 -11.1111111)'::geometry, 20.1,20.1);", cursorOptions=256, boundParams=0x0) at postgres.c:875 #26091 0x0000000000780ff1 in pg_plan_queries (querytrees=0x8071340, query_string=query_string@entry=0x5bbcef0 "SELECT ST_WrapX('LINESTRING(-11.1111111 70,70 -11.1111111)'::geometry, 20.1,20.1);", cursorOptions=cursorOptions@entry=256, boundParams=boundParams@entry=0x0) at postgres.c:966 #26092 0x0000000000781380 in exec_simple_query ( query_string=0x5bbcef0 "SELECT ST_WrapX('LINESTRING(-11.1111111 70,70 -11.1111111)'::geometry, 20.1,20.1);") at postgres.c:1158 #26093 0x0000000000782db9 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x5c66d50, dbname=<optimized out>, username=<optimized out>) at postgres.c:4315 #26094 0x00000000006f86ae in BackendRun (port=0x4d6f7c0, port=0x4d6f7c0) at postmaster.c:4523 #26095 SubPostmasterMain (argc=argc@entry=3, argv=argv@entry=0x5c66b10) at postmaster.c:5046 #26096 0x0000000000910b5f in main (argc=3, argv=0x5c66b10) at main.c:187