Python bindings: fix use-after-free on sub-geometries of a feature's geometry

[alonfaraj]

What does this PR do?

When getting a sub-geometry from a feature's geometry and the feature goes away, using the sub-geometry segfault:

from osgeo import ogr

f = ogr.Feature(ogr.FeatureDefn())
f.SetGeometry(ogr.CreateGeometryFromWkt("POLYGON ((0 0,0 1,1 1,0 0))"))
ring = f.GetGeometryRef().GetGeometryRef(0)
del f
ring.GetPointCount()  # segfault

Reproduced on 3.13.3 and master .

Fix

Each geometry a feature hands out now keep a weak reference to that feature. When you get a sub-geometry from it, the sub-geometry registered with the same feature. When the feature dies, all of them are invalidated together. Result with an exception instead of a crash, like GetGeometryRef() case.

What are related issues/pull requests?

AI tool usage

• AI (Y-a-t-il-un-Copilot-dans-l'avion, Chat-j'ai-pété, Jean-Claude Dusse or something similar) supported my development of this PR. See our policy about AI tool use. Use of AI tools must be indicated.

Tasklist

• Make sure code is correctly formatted (cf pre-commit configuration)
• Add test case(s)
• Add documentation
• Updated Python API documentation (swig/include/python/docs/)
• Review
• Adjust for comments
• All CI builds and checks have passed
• ADD YOUR TASKS HERE

Environment

Provide environment details, if relevant:

• OS: Ubuntu 26.04
• Compiler: gcc (Ubuntu 15.2.0-16ubuntu1) 15.2.0

[dbaston]

A Geometry is not necessarily owned by any feature. Maybe better to have Geometry.__del__ invalidate any references it has handed out, the same way that Feature does?

For example, the following still segfaults with this PR:

>>> g = ogr.CreateGeometryFromWkt("POLYGON ((0 0, 1 0, 1 1, 0 0))")
>>> g1 = g.GetGeometryRef(0)
>>> g.Destroy()
>>> g1.ExportToWkt()
zsh: segmentation fault  python3

[alonfaraj]

Good point, thanks!
I'll switch to your approach: Geometry will track the sub-geometries it hands out, Destroy() will invalidate them, and the feature's invalidation will cascade down through them. This also drops the _owner_feature weakref and covers sub-geometries taken before SetGeometryDirectly().

But I think we can skip __del__: a sub-geometry already keeps its parent alive via _parent_geom, so only an explicit Destroy() can free the parent out from under it. What do you think?

[dbaston]

a sub-geometry already keeps its parent alive via _parent_geom

I thought maybe we could get rid of this, but perhaps someone depends on this behavior. So your approach sounds good.

[alonfaraj]

So your approach sounds good.

Reworked based on this