Repository navigation
system.macintosh iterative walk SEGFAULTS (exit 139); deterministic reproducer for #828/#857 dbgeteof null-deref family #864
Description
Rationale
Walking system.macintosh with a plain iterative table walk SEGFAULTS (exit 139), reproducible on both Virgin.root and dist Frontier.root. Every other system subtree walks clean. Likely the same dbgeteof-null-deref family as #828 and #857 (name resolution over an ODB-backed value with nil databasedata). Critical value: provides a deterministic reproducible case for what is intermittent in #828/#857 — this is a reliable test harness for the underlying bug.
Current State
Verified reproduction (Unit 3.3+, deterministic):
- Iterative table walk over
system.macintoshvia frontier-cli sizeOf()ornameOf()on each key- Exit 139 (SEGFAULT)
- Reproducible on both Virgin.root and dist Frontier.root
- Every other system.* subtree walks cleanly
Context:
- Related to Latent: in-memory hash node takes on-disk resolution path -> NULL deref (dbgeteof via hashresolvevalue) #828 (latent in-memory hash node takes on-disk resolution path → NULL deref)
- Related to test_window_bridge: intermittent init-phase SIGSEGV (~66 percent of runs) before any test executes #857 (TCP getCurrentTime: number() on raw RFC-868 bytes does not big-endian-unpack)
- Likely root cause:
dbgeteofcalled on ODB-backed value with nildatabasedata(GIL holder has no active database context)
Impact:
- Any code iterating system.macintosh crashes
- Blocks audits, tooling, or introspection of macintosh constants
- Deterministic crash provides reliable test case for debugging
Desired Outcome
Provide a deterministic reproducer for the dbgeteof-null-deref family of bugs. Use this to:
- Trace the exact call chain (LLDB backtrace)
- Identify which operation on system.macintosh triggers the crash
- Fix the root cause (likely: nil databasedata guard or context restoration)
- Verify against both Latent: in-memory hash node takes on-disk resolution path -> NULL deref (dbgeteof via hashresolvevalue) #828 and test_window_bridge: intermittent init-phase SIGSEGV (~66 percent of runs) before any test executes #857
Recommendation
- Reproduce with LLDB:
frontier-cli --protocol < <script that walks system.macintosh> - Capture full backtrace at SEGFAULT
- Identify the
dbgeteof(or similar) call with nil databasedata - Compare against Latent: in-memory hash node takes on-disk resolution path -> NULL deref (dbgeteof via hashresolvevalue) #828/test_window_bridge: intermittent init-phase SIGSEGV (~66 percent of runs) before any test executes #857 for shared pattern
- Implement fix (likely: check databasedata before calling dbgeteof, or restore context)
- Verify:
sizeOf(@system.macintosh)and iterative walk both succeed
Exit Criteria
- LLDB backtrace captured and analyzed
- Root cause identified (dbgeteof with nil databasedata or similar)
- Crash no longer occurs on system.macintosh walk
-
sizeOf(@system.macintosh)succeeds - Iterative
nameOf()walk over all keys succeeds - Fix applies to Latent: in-memory hash node takes on-disk resolution path -> NULL deref (dbgeteof via hashresolvevalue) #828/test_window_bridge: intermittent init-phase SIGSEGV (~66 percent of runs) before any test executes #857 intermittent failures (or root cause is confirmed different)
Related Context
- Found by: Unit 3.3+ diagnosis
- Related issues: Latent: in-memory hash node takes on-disk resolution path -> NULL deref (dbgeteof via hashresolvevalue) #828 (latent in-memory hash node NULL deref), test_window_bridge: intermittent init-phase SIGSEGV (~66 percent of runs) before any test executes #857 (TCP getCurrentTime unpack issue — may be same bug family)
- Reproduction:
frontier-cli --protocol+ iterative walk oversystem.macintosh - Value: deterministic reproducer for intermittent crashes in Latent: in-memory hash node takes on-disk resolution path -> NULL deref (dbgeteof via hashresolvevalue) #828/test_window_bridge: intermittent init-phase SIGSEGV (~66 percent of runs) before any test executes #857
- Code: dbgeteof calls, name resolution on ODB-backed values, databasedata context management
- Thread safety: GIL model; check if databasedata is properly restored across yields
Activity
jsavin commentedon Aug 11, 2026
ODB Census State-Dependence Finding (2026-08-11):
system.macintosh SEGFAULTS when descended mid-walk from its parent, BUT all six children (282 values total) walk cleanly as separate fresh processes.
Implication: The crash is SESSION/STATE-DEPENDENT, not DATA-DEPENDENT. The stored data itself is intact.
Materially narrows the repro:
Next step: When reproducing with LLDB, trace the exact state at crash — focus on walk context (parent reference, depth, enumeration state) rather than on data content.
jsavin commentedon Aug 16, 2026
Corroboration: does NOT reproduce in a pure-C walk (2026-08-15)
While building the
--diff-rootsequality walker (root-build Step 1), a pure-C recursive walk descendedsystem.macintoshwithout crashing.Conditions:
Virgin.root, opened read-only (dbopenfile(fnum, true)), no interpreter booted, no startup scripts -- onlydb_format_prepare_runtime(), the same minimal init--migrateuses.system.macintoshwas descended from its parent, in-process, mid-walk, as part of a full-root traversal -- i.e. the condition described here as the trigger, not an isolated subtree walk.system.macintosh. No SIGSEGV, exit 0.dbclose()-> reopen -> walk) and across the full-root self-diff runs; clean every time.Contrast with the census (
planning/census-data/odb_census_2026-08-11.tar.gz, README CAVEAT 1): the interpreter-driven walker segfaulted on this subtree and its 282 rows had to be recovered by walking each of the 6 children in its own process (mac_*.tsv.1).Reading: same data, same descent-from-parent pattern, opposite outcome -- the differentiator is the interpreter, not the stored values. That agrees with this issue's own "session/state-dependent, not data-dependent" assessment and with the census's read.
Practical consequence: whatever the root cause, it is not reachable from a pure value-level walk that never resolves names or evaluates. Anything needing to audit
system.macintoshcan do so today via a C walk; only interpreter-mediated traversal is blocked.Offered as evidence narrowing the search area, not as a fix -- the underlying
dbgeteof-null-deref family (#828/#857) is untouched by this.feat(odb): --diff-roots value-level equality walker (root-build Step …