The ~1/9 wasm trap on CvPcb open ("index out of bounds" / "indirect call to
null" in a footprint AsyncLoad pool worker, then eeschema aborting on the
broken future — and the eeschema-fp-selector "CI-only" trap family, which was
never llvmpipe-specific) was wxString's UTF-8 build mutating SHARED strings on
read-only access from concurrent pool workers: every iterator ctor/dtor
spliced an intrusive list inside the string object, and torn splices wrote
through dead node pointers into other threads' stack frames. Second defect:
the UTF-8 position cache returned stale offsets when another thread's string
died and its address was reused.
Fixed in the wxwidgets fork (per-thread iterator registry + position cache
disabled under Emscripten) — kicad is untouched and AsyncLoad keeps its full
multi-worker fan-out. Falsified along the way (all perturbation masks, not
fixes): serializing the items, mimalloc vs dlmalloc, pthread stack size,
ASYNCIFY_STACK_SIZE, private-copy EnumFromStr, hot-path logging.
New red-first standalone app tests/apps/standalone/wxstring-mt (+ spec
coroutine-wxstring-mt.spec.ts, wx-chromium + coroutine-firefox): shared-string
compares alternating with wide-literal conversions reproduce the exact editor
trap signatures on the unfixed wx and run 4.7M rounds clean on the fixed one;
the pos-cache address-reuse dance corrupts on the first reuse before and
survives 673 after; two guard modes keep the iterator fix-up feature honest
(incl. an anti-elision liveness check — balanced register/unregister pairs in
tight loops can legally be optimized away, so a naive red test tests nothing).
Verification: wx+coroutine suites 382 passed; in-app AsyncLoad hammer 3x1000
rounds clean (baseline died <10); eeschema-assign-footprints spec 20/20
firefox + 20/20 chromium on the final build; lint:determinism clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rb9jsqtHsC3tHTaJ45244j
The spec's boot gates (canvas, registry, title) are all wx-side and go
live seconds before WasmTool drops its opaque boot overlay (ready only
flips after the collab seed + waitForWxUi). The Tools click landed on
the overlay, the popup never opened, and the menu-item wait timed out —
flaky on CI (the 1s title poll sometimes samples after overlay unmount),
100% locally. Add the inset-0.z-30 count-0 guard the chrome-toggle /
tool-switch / quit-* specs already use.
Verified: web-chromium 5/5, web-firefox 8/9 (was 0/5, 0/1). The one
remaining firefox failure is a distinct pre-existing wasm trap on the
CvPcb-open path (EVT.MENU dispatch → "index out of bounds" in a worker),
same signature as the eeschema-fp-selector CI trap — now known to
reproduce on macOS real GL too. Left as a TODO(cvpcb-open-trap) in the
spec; needs a debug-symbol repro.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rb9jsqtHsC3tHTaJ45244j
The three page.waitForTimeout calls in eeschema-assign-footprints.spec.ts
are legitimate interaction dwells (two poll intervals that pump the wx
event loop inside asserting loops, one first-paint settle before a
screenshot), but were unannotated, so the determinism guard failed CI.
Mark each with a `dwell:` note per tests/TESTING.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
