Geography support is blocked at the extension runtime: geog_in / geog_area SIGSEGV in the loaded DuckDB extension

[estebanzimanyi]

Surfaced while assessing the feasibility of adding cross-binding geodetic temporal spatial-relationship test coverage to MobilityDuck (analog of PyMEOS's TestTGeogPointTemporalSpatialOperations). The conclusion is that the gap is not test-coverage and not addressable with test additions alone — it is an extension-runtime-stability issue documented in MobilityDuck itself.

Documented evidence in this repo

src/geo/stbox_functions.cpp (lines 23–26 and 1146):

MEOS stbox_area() can SIGSEGV on geodetic boxes (3D / PolyhedralSurface path). For geodetic footprints use spherical rectangle area (WGS84 sphere); avoids MEOS geog_in / geog_area faults.

closely enough for tests; avoids MEOS geog_in / geog_area which can SIGSEGV in this extension.

A C++ Spherical_lonlat_rect_area_m2 is in place as a deliberate sidestep of the MEOS geography path inside the loaded extension.

Structural consequences

Step	State
GeoTypes::GEOMETRY() exists	✅ used for the geo-argument side of all spatial-rel UDFs
GeoTypes::GEOGRAPHY() exists	❌ no such LogicalType
spatial-rel UDFs register {TGEOGPOINT, GEOGRAPHY} overloads	❌ only {TGEOGPOINT, GEOMETRY}, which MEOS rejects via ensure_same_geodetic_tspatial_geo
tgeogpoint parity tests cover tDwithin / tIntersects / tDisjoint / tTouches	❌ 042_tgeogpoint_parity.test has zero such queries — the absence is principled given the above

So the temporal type tgeogpoint is registered and round-trips through IO, but invoking a spatial relationship on it against a static geo argument is structurally unreachable today because the binding has no geodetic static type to pair with it, and adding one would re-enter the documented geog_in SIGSEGV path.

Plausible root causes (each diagnosable)

• PROJ initialization missing in the DuckDB-extension load path. geog_in uses PROJ for SRID transforms; standalone MEOS initialises PROJ via meos_initialize, but the in-extension MEOSLifecycle / equivalent may not configure PROJ search paths the way standalone does. (PROJ_DATA env-var is set in the standalone test harness but may not propagate into the loaded extension's process.)
• Allocator mismatch. Some MEOS geography helpers expected to be called inside a PostgreSQL memory context (palloc); MobilityDuck's extension context is plain malloc/free, and a palloc cousin used by geog_in (or a lwgeom_* helper it calls) may dereference an uninitialised memory context.
• *_meos.c linkage. geog_in may have a path defined in a meos/src/geo/*_meos.c file that is excluded from the PostgreSQL-extension build (the same class of issue as MobilityDB#1088's tgeo_from_base_temp — libmeos-only constructors), causing a deferred undefined-symbol or partial-link failure that manifests as a runtime crash rather than a load-time error.
• Thread-safety. DuckDB is multithreaded; MobilityDB#815 made MEOS thread-safe, but PROJ's PJ_CONTEXT is not implicitly per-thread — a shared PROJ context can crash under concurrent geog_in calls.

Dependency-ordered path to unblock geodetic spatial-rel parity in MobilityDuck

1. Root-cause and fix the geog_in / geog_area SIGSEGV inside the DuckDB extension (issue this one).
2. Add GeoTypes::GEOGRAPHY() LogicalType + IO mirroring GEOMETRY().
3. Register {TGEOGPOINT, GEOGRAPHY} and {GEOGRAPHY, TGEOGPOINT} overloads for tDwithin / tIntersects / tDisjoint / tTouches.
4. Add the geodetic spatial-rel parity test cases (the PyMEOS / GoMEOS / JMEOS fixtures already encode the geodetically-correct expected values that mirror MobilityDB#1088).

Until step 1 lands, geodetic spatial-rel testing in MobilityDuck is structurally unreachable. The cross-binding test-coverage parity work tracked in PyMEOS-side analyses correctly stops here for MobilityDuck.

Filed as the precise predicate for MobilityDB#1088's downstream propagation in MobilityDuck.

[estebanzimanyi]

Update from the SIGSEGV diagnosis (2026-05-20): Bug 1 (geog_in WKT fall-through NULL dereference) is root-caused and fixed — see MobilityDB#1089 / PR#1090 (A/B-verified: unpatched libmeos SIGSEGV exit 139 → patched PASS exit 0; both libmeos + the PG extension build clean per the MobilityDB#1088 lesson).

Bug 2 (stbox_area / geog_area on geodetic 3D / PolyhedralSurface) does NOT reproduce on current MobilityDB master. I ran four progressively harder geodetic-3D probes against a clean libmeos built from current master (d4cc7d2):

input	result
GEODSTBOX Z((1.0,1.0,0.0),(2.0,2.0,1000.0)) — mid-latitude	12 305 128 751 m² (no crash)
GEODSTBOX Z((-10.0,-5.0,-500.0),(10.0,5.0,500.0)) — equator-crossing	2.48 × 10¹² m² (no crash)
GEODSTBOX Z((170.0,85.0,0.0),(-170.0,89.0,500.0)) — near-pole, antimeridian	5.12 × 10¹⁰ m² (no crash)
GEODSTBOX Z((0.0,-89.0,0.0),(180.0,89.0,2000.0)) — whole hemisphere	2.55 × 10¹⁴ m² ≈ ½ Earth surface (no crash)

All boxes parsed with the genuine 3D Z flag set (flags=0xb0 = X|Z|GEODETIC), all flowed through stbox_geo → box3d_to_lwgeom → POLYHEDRALSURFACETYPE → geog_area / lwgeom_area_spheroid, and all returned sensible values. The crash MobilityDuck's src/geo/stbox_functions.cpp:23-26,1146 comments document was real at some earlier point in MEOS but has been fixed upstream — the workaround was never updated.

Recommendation: the Spherical_lonlat_rect_area_m2 / Geodetic_stbox_footprint_area C++ helpers can be retired in favour of direct stbox_area(box, true) calls; the comments at lines 23-26 and 1146 should be removed or rewritten to reflect that geodetic stbox area now works in MEOS. With Bug 1's fix (PR#1090) landed and Bug 2 already fixed upstream, the gating story for MobilityDuck geodetic spatial-rel support reduces from "upstream SIGSEGV fix" to "register GeoTypes::GEOGRAPHY() LogicalType + {TGEOGPOINT, GEOGRAPHY} UDF overloads + add the geodetic spatial-rel parity tests" — all binding-side, no upstream blockers, all tractable.