Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GEOS 3.13 is causing curve geometry tests to segfault #478

Open
brendan-ward opened this issue Sep 27, 2024 · 3 comments
Open

GEOS 3.13 is causing curve geometry tests to segfault #478

brendan-ward opened this issue Sep 27, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@brendan-ward
Copy link
Member

First observed in the conda tests, which are pulling in GEOS 3.13 which added support for curve geometry types. I can reproduce the segfault locally when installing deps from conda-forge and building latest pyogrio.

It looks like the latest GDAL Docker versions we're testing against still use GEOS 3.12, so we aren't yet seeing this issue in the other CI tests - but it may be lurking around the corner. Until there is a version of GDAL built against GEOS 3.13 it is harder to test against this configuration outside of the conda packages.

@brendan-ward brendan-ward added the bug Something isn't working label Sep 27, 2024
@brendan-ward
Copy link
Member Author

Looks like homebrew GDAL 3.9.2 includes GEOS, so I should be able to compile against that locally and see if this segfaults when using GDAL outside of conda-forge.

@brendan-ward
Copy link
Member Author

Narrowed it down a bit: this happens where use_arrow=True when reading certain curve geometries available in our test suite:

  • CurvePolygon
  • MultiSurface

(we don't have Surface at the moment)

Curve doesn't segfault but raises another error.

I can also reproduce the issue locally when compiling against homebrew GDAL and compiling shapely against GEOS 3.13, which makes this easier to investigate.

When we are reading geometries using without using Arrow, we can detect if a geometry is nonlinear and have GDAL force it to a linear type before we read it. However, when using Arrow, we read the raw WKB with GDAL, and count on shapely to be able to parse it. The segfault is occurring in shapely.from_wkb with these nonlinear types.

However, GEOS 3.13 appears to work fine:

❯ geosop -a "010C00000001000000010A00000001000000010200000004000000D2936CD801D357C01F7CE5EED1AE4F402EDD365958A657C065B26029F3884A4056D
1DE08466D52C0ED7574EB21134E40D2936CD801D357C01F7CE5EED1AE4F40"
MULTISURFACE (CURVEPOLYGON ((-95.29698763468994 63.36578165250125, -94.5991423640996 53.06992070409323, -73.7073995758013 60.149472648492385, -95.29698763468994 63.36578165250125)))

@theroggy
Copy link
Member

theroggy commented Sep 28, 2024

Shapely with GEOS 3.13 also seems to crash on the wkt:

I've had a quick look at the shapely code, but don't immediately see where it can go wrong specifically on the curve types...

So I opened an issue in shapely: shapely/shapely#2159

import shapely

wkt = "MULTISURFACE (CURVEPOLYGON ((-95.29698763468994 63.36578165250125, -94.5991423640996 53.06992070409323, -73.7073995758013 60.149472648492385, -95.29698763468994 63.36578165250125)))"
print(shapely.from_wkt(wkt))
print("here")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants