This repository has been archived by the owner on Sep 19, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 79
Panics on prepared geometry calls #11
Comments
can confirm issue and fix
|
pmezard
added a commit
to pmezard/gogeos
that referenced
this issue
Jan 10, 2017
The problem is twofold: - In Geometry.Coords() we have to make sure the parent Geometry outlives the processing of the coordinates array. - The previous condition is not enough when the geometry comes from Shell() or Holes(), which return internal objects. We have to make sure the shell/hole parent geometry outlives the shell/hole instance. The fix is similar to the one suggested in paulsmith#11. There are probably a lot of places where either previous conditions are required, I have not checked all the code. Note: this change the minimum required Go version to 1.7. I tried to play build tag games to have empty versions of the runtime.KeepAlive call, and failed. Fixes paulsmith#8
I seem to be having the same problem when creating geometries from WKT. Anyone have any ideas on a general solution? |
jdejesus007
added a commit
to Jlectronix/gogeos
that referenced
this issue
Nov 26, 2019
The problem is twofold: - In Geometry.Coords() we have to make sure the parent Geometry outlives the processing of the coordinates array. - The previous condition is not enough when the geometry comes from Shell() or Holes(), which return internal objects. We have to make sure the shell/hole parent geometry outlives the shell/hole instance. The fix is similar to the one suggested in paulsmith#11. There are probably a lot of places where either previous conditions are required, I have not checked all the code. Note: this change the minimum required Go version to 1.7. I tried to play build tag games to have empty versions of the runtime.KeepAlive call, and failed. Fixes paulsmith#8 per -> pmezard
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have observed panics when prepared geometry objects are used:
I tried to recreate the behaviour in a test, but I couldn't, at least not consistently. It is related to Go's GC cycles and the finalizer calling
cGEOSGeom_destroy(ptr)
on the original Geometry. As a workaround, I added:It fixes the problem by preventing the Geometry from being garbage-collected, but it is not very elegant.
Thoughts? Thanks
The text was updated successfully, but these errors were encountered: