Stale .shared_module ABI mismatch dies as an opaque SIGSEGV at registration — needs a fail-closed ABI stamp

[borisbat]

Symptom

Loading a .shared_module built against an older daslang crashes with a bare segfault during Module::Initialize, deep inside type walking:

CRASH: EXCEPTION_ACCESS_VIOLATION reading 0x24
  das::TypeDecl::hasStringData
  das::TypeDecl::hasStringData
  das::BasicStructureAnnotation::hasStringData
  register_dyn_Module_dasDUCKDB
  das::Module::Initialize

Repro (before rebuild): daslang.exe -load_module D:/DASPKG/dasDuckDB daslib/duckdb_boost.das with a DLL built 2026-07-04 and a daslang from master ≥ 52c8bcc.

Root cause (bisected)

#3424 (distinct types, merged 2026-07-10) added virtual bool rtti_isDistinctTypeAnnotation() to the base annotation class. That inserts a vtable slot, so annotation objects constructed by a pre-#3424 DLL dispatch every later virtual through a shifted slot when the new host binary calls them — garbage dispatch, segfault. Bisect: 1828f3af5 (parent) loads the old DLL fine; 52c8bccb4 (the #3424 merge, only commit in the gap) crashes; rebuilding the DLL against current master makes it load cleanly. The break itself is legitimate (headers changed ⇒ rebuild shared modules) — the problem is the failure mode.

Ask

Same fail-closed family as the silent-dlopen 20605: stamp .shared_modules with an ABI token (e.g. a hash folding the sizes/vtable-shape-sensitive headers, or even just DAS_VERSION + a hand-bumped ABI counter) checked in Module::Initialize before any virtual is called, so a stale DLL produces error: module 'dasDUCKDB' was built against an incompatible daslang (ABI <x>, host <y>) — rebuild it instead of a segfault nobody can attribute. Every daspkg checkout DLL built before 2026-07-10 currently hits this.

🤖 Generated with Claude Code