ReviewOS

home-lang/home

Native home_rt: eliminate state-dependent AtomStringImpl GC assertion

#568
Open chris opened this 9 days ago ·
9 days ago

Summary

The native home_rt suite can fail nondeterministically in JSC GC while sweeping a JSString:

WTFCrashWithInfoImpl
WTF::AtomStringImpl::remove
WTF::StringImpl::~StringImpl
JSC::JSString::destroy
JSC::MarkedBlock::Handle::specializedSweep

The process exits from SIGTRAP (build reports code 133). A run on 2026-08-31 reached jsc.webcore_globals.test.Response constructed from a ReadableStream drains to the original string before the assertion. An earlier crash report from 2026-08-30 has the same AtomStringImpl::remove signature, so this predates the current native FS/StatFS ownership checkpoint.

Evidence

  • failing command: zig build test -Dfilter=home_rt -j1
  • failing run: signal-derived exit 133 during test 1623/1835
  • exact filtered test under the same native launcher: 20/20 passed
  • clean full retry: 1,816 passed, 19 skipped, 0 failed
  • crash reports:
    • test-2026-08-30-110824.ips: identical AtomStringImpl::remove assertion
    • test-2026-08-31-141445.ips: current occurrence

This points to prior-suite state or GC timing rather than deterministic behavior in the named Response test.

Acceptance criteria

  • Reproduce under a deterministic test order or explicit GC stress.
  • Identify the over-release/cross-VM ownership path that leaves an atomized string invalid during sweep.
  • Add a focused native regression that fails before the fix.
  • Pass repeated filtered stress and repeated complete home_rt runs without the assertion.

Tracks the native stability work required by #66. Keep separate from other deterministic native crashes.

9 days ago

Progress in 31c865d1ba8a13f422a7abccc30d0ef6cb9a0e65 (fix(runtime): restore JSC atom-table ownership), also resolving the concrete plain-adapter trap in #590.

A fresh crash report exposed the invariant directly in JSC::Heap::requestCollection: the active VM's atom table differed from WTF::Thread::currentSingleton().atomStringTable() when an allocating Zig host callback created a typed array during microtask draining. The shared callback-registration layer now installs a per-function C trampoline that restores the raw context's VM atom table before invoking any Zig callback. This covers all reduced-realm bindings rather than special-casing crypto or GC timing.

Evidence after the fix:

  • the formerly intermittent key-object reproducer completed in 30 of 30 fresh processes (before-fix baseline: 2 traps in 3 runs);
  • the full unchanged 17-file js/node/crypto adapter directory completed with 851 pass, 0 fail, 0 unsupported, 23 existing TODO;
  • two consecutive complete home_rt runs each completed with 1,814 passed, 19 skipped, 0 failed (1,833 total).

I am leaving #568 open: the new evidence identifies and repairs a cross-VM atom-table ownership path and repeated full-suite stability is green, but the issue's stricter requirement for a focused deterministic native regression that demonstrably fails before the fix has not yet been met. I do not want to weaken that acceptance criterion or claim the older sweep-time signature is conclusively closed without it.

Sign in to comment on this issue.