Three orchestration fixes, validated end-to-end on the Hetzner ccx53
(run 27280051992, 1h14m41s vs 4h05m baseline, e2e identical):
- docker-compose CPU/memory caps were hardcoded to dev-Mac defaults
(10 CPUs / 32G); now env-tunable via KICAD_DOCKER_CPUS/KICAD_DOCKER_MEM
(CI exports nproc/110G — the 32-core runner was compiling on 10 cores).
- docker/build.sh: split build_app into compile_app (container) +
postprocess_app (host-side dyncall shims + finalize + asyncify + -O2)
and added KICAD_PIPELINE=1 mode that overlaps each tool's host-side
wasm-opt with the next tool's container compile (max 2 concurrent
postprocesses — pcbnew -O2 peaks ~34G RSS). Also: comma-separated app
lists for cheap pipeline repros.
- get-wasm-opt.sh: Binaryen default 121 -> 130 (fixes the v121 -O2 lock
convoy, ~9x) and BINARYEN_BUILD_FROM_SOURCE=1 support: the official
x86_64-linux release tarballs (Alpine/musl, no LTO, assertions on) run
asyncify 4x slower than a stock gcc -O3+LTO build with sha256-identical
output; self-build takes ~5 min and is instantly repaid.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Two related fixes for Chrome-specific WASM-runtime issues reported when
running a manually-loaded session (line tool wouldn't even toggle on click;
log filled with 'Uncaught (in promise) unwind' and stderr-tagged
[WASM_FCONTEXT]/[DIAG_*] spam):
1) scripts/common/apply-asyncify.sh — run 'wasm-opt -O2' as a separate
pass after '--asyncify'. Without this, large asyncify-instrumented
coroutine-entry trampolines (notably libcontext's wasm_fcontext_entry
and COROUTINE<int,TOOL_EVENT const&>::callerStub) exceed V8's
per-function locals limit and silently stall on first fiber entry,
leaving the toolbar click dispatched in C++ but the tool never
activating its 'running=1'/[checked] state in the user's Chrome.
Firefox tolerates the unoptimised version, so tests on Firefox passed
while real Chrome stalled. The -O2 pass shrinks every instrumented
function back under the threshold, fixing the family of stalls
systemically (no more per-function removelist whack-a-mole).
The removelist still contains setupUIConditions() etc. as a safety
net — they're now redundant under -O2 but harmless.
Bundle: 338 MB -> 187 MB raw (~45% smaller); test runtime nearly
halves because parse is faster. See DEBUG.md §7 and
memory/bundle-size-asyncify-optimization.md.
2) wxwidgets submodule bump (d1d1627 -> a998a8d) — wasm/dialog.cpp:
startModal()'s setTimeout-based runEventLoop now awaits
ccall('ProcessEvents', ..., {async:true}) so the Promise rejection
from an asyncify-suspended ProcessEvents is caught by the existing
try/catch instead of escaping as an 'Uncaught (in promise) unwind'
page error.
Verified: npm run test:kicad:chrome and test:kicad:firefox both pass on
the rebuilt wasm; zero pageerror events; user-reported manual flow now
selects the Draw Lines tool and draws successfully.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- build-pcbnew.sh: add --diag=<gal,coroutine,ctor,all> -> -DKICAD_DIAG_*,
off by default (forwarded by docker/build.sh)
- diagnostics.js: emit at console.log level (no longer error/warn); still
gated by SHIM_DIAGNOSTICS=1
- apply-asyncify.sh: exclude PCB_EDIT_FRAME::setupUIConditions() from
asyncify instrumentation (V8 cannot run the instrumented huge function
on the rewound ctor stack -> Chrome startup stall; Firefox unaffected)
- DEBUG.md: reusable WASM/asyncify/browser debugging guide, diagnostic
flag docs, and a production-build (release + -O2 asyncify) recipe
- tests: standalone coroutine vcall/gl repro probes
- bump kicad + wxwidgets submodules (diagnostic gating / debug cleanup)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Main-repo side of a multi-part WIP covering the KiCad WASM tool-selection
and nested-Asyncify work. Submodule commits are in kicad@f6e9239aaa
(libcontext hygiene) and wxwidgets@bb80f91e8b (auibar registration +
dialog diagnostics).
## scripts/common/inject-dyncall-shims.sh
Wrap Asyncify.handleSleep / allocateData to save-and-restore Asyncify.currData
around each EM_ASYNC_JS sleep. This fixes the nested Asyncify collision where
a fiber swap that fired during a modal's event loop clobbered currData, and
the modal's later doRewind used the fiber's buffer and hit "RuntimeError:
index out of bounds". Root cause documented as Emscripten Issue #9153
(wontfix upstream).
Diagnostic-rewind logging (forcedBottomOfCallStack, callStack traces) is
retained to help future debugging of Asyncify state corruption.
## tests/
- tests/playwright-kicad.config.ts: add `channel: 'chrome'` for the
chromium project so --project=chromium --headed uses system Chrome
(real GPU) instead of SwiftShader on ARM Mac. Also switch trace to
retain-on-failure + screenshot on-failure for easier E2E debugging.
- tests/kicad/pcbnew.spec.ts: replace `tool.checked` assertions with a
label-suffix check (`[checked]`) since our auibar registration encodes
checked state in the label (no schema change to the registry).
- tests/apps/Makefile.wasm: add `coroutine-nested` build target + include
it in the all: list.
- tests/apps/standalone/coroutine/: kicad_coroutine_harness.h + test app
reproducing KiCad COROUTINE semantics against real libcontext.
- tests/apps/standalone/coroutine-nested/: nested_test.cpp reproduces the
EM_ASYNC_JS-modal + fiber-swap nesting bug in isolation. 8 scenarios
from baseline_modal_alone through nested_fibers_inside_modal.
- tests/e2e/coroutine.spec.ts + coroutine-nested.spec.ts: Playwright specs
that load the standalone apps and assert all case cases pass via
[COROUTINE_TEST] SUMMARY log parsing.
## research/ and features/browser-tools/
Three background docs capturing the investigation trajectory:
- features/browser-tools/0001-kicad-wasm-tool-activation-investigation.md
Early investigation: why tools don't activate; initial dynCall-empty-
callback hypothesis.
- features/browser-tools/0002-wasm-coroutine-deep-dive.md
Deep dive on Asyncify internals, fiber API, QEMU's coroutine-wasm
reference implementation.
- features/browser-tools/0003-wxauitoolbar-registration-fix.md
The narrow fix: why wxAuiToolBar needs a registration block, where to
add it, what the fallback plan is.
- research/threading_1.md: corrected root-cause analysis after reading
runtime logs — nested-Asyncify currData collision, Emscripten #9153.
- research/threading_2.md: extended research on alternative approaches
(JSPI/WasmFX/state-machines) and why they don't help here.
## Submodule pointer updates
kicad: f6e9239aaa (wip: libcontext WASM hygiene cleanup)
wxwidgets: bb80f91e8b (wip: wxAuiToolBar element-registry registration +
dialog diagnostics)
## Open threads not yet in scope
- Firefox/Chrome divergent behavior: "indirect call signature mismatch"
traps in Firefox vs renderer crash in system Chrome (tracked in
plans/peaceful-hugging-pnueli.md and the research docs).
- E2E pixel-diff for Draw Lines fails because the test's diff region does
not cover where the line is actually drawn; tool activation works, the
line is visible in test-results/pcbnew-draw-lines-02-after-drawing.png.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Build improvements:
- Change -O0 to -O1 to fix "local count too large" asyncify error
- Add wasm-emscripten-finalize to host (Docker OOMs on large WASM)
- Use -gseparate-dwarf for smaller main binary with debug info
- Build native protoc for code generation
- Add more functions to asyncify removelist
Runtime fixes:
- Add inject-dyncall-shims.sh to fix "dynCall_* is not defined" in Emscripten 4.x
- Update wxwidgets with browserInfo.name fix
New stubs and bindings:
- Add Embind bindings for JavaScript interop
- Add stubs for scripting, API plugin, PCB frame, navlib
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
