app

KiCad - the KiCad Bridge

Public Made by Adom

by adom

Drive your own KiCad from an AI, in the background: open every editor, read the whole board as data (the EDA Bridge Standard board model), stack-up, part heights, netlists, place, route, pour, DRC and exports.

kicadpcbschematicedabridgeabadom-bridgedesktop-app
Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests1 Activity
Closed general

Bridge process crashed once mid show_3d_chip on 0.9.102 (auto-respawned); needs crash logging + guardian/menu-walk ctypes audit

John Lauer · ·closed by John Lauer

During the 2026-08-15 verb-suite run on 0.9.102, the bridge PROCESS died mid-show_3d_chip (client saw "error sending request for url http://127.0.0.1:63999/command" = connection reset; the next two verbs hit a dead port) — and notably, ab auto-respawned it and the rest of the run passed on the new instance (a good #56 data point: recovery worked this time).

Suspects for the native crash (new code in 0.9.101/0.9.102, all ctypes-heavy):

  1. The guardian's _sweep_suppress — EnumWindows every 0.5s from a daemon thread with a WNDENUMPROC callback + SetWindowLongPtrW on windows that may be mid-destruction.
  2. The Win32 menu walker (win_menu.py) — GetMenu/GetSubMenu recursion with c_void_p juggling, invoked in the same flow that died.
  3. _screenshot_hwnd GDI churn under the kicad_state that ran nearby.

No crash log exists: the manual instance is launched with -WindowStyle Hidden and NO output redirect. Next manual relaunch must redirect stdout/stderr to a file so a native traceback/faulthandler output is captured. Also worth adding faulthandler.enable(file=...) at server boot.

Meanwhile: show_3d_chip/show_3d_board are back in the daily-suite baseline as known-flaky when run cold+isolated (they pass in full-run order once KiCad is warm; the cold single-call path is also squeezed by ab #73's relay caps). The foreground contract is unaffected — the run that surfaced this crash had ZERO foreground violations.

1 Reply

John Lauer ·

Crash logging is in place as of 0.9.111 (live on ConfRoomROG now): faulthandler.enable(all_threads=True) at server boot, dumping to stderr. Since ab 2.0.44 the managed spawn captures bridge stderr into ~/.adom/bridge-logs/kicad.log (verified: that capture is how the runtime-provisioning crash in adom/adom-bridge#78 was diagnosed), so the next native fault leaves every thread's stack instead of a silent dead port. On the manual-instance caveat: the manual :63999 workaround instance is retired, ab 2.0.46 fixed the respawn dead-end and the bridge now runs ab-managed with full log capture, so the no-redirect gap no longer exists. Stability data since filing: the ctypes-heavy paths (guardian sweep, menu walker, GDI capture) have run through the full-circle demos, three complete 8-surface part proofs, and a full kicad_demo on a fresh box, with zero process deaths since 0.9.102. Closing; if it recurs we will have the faulthandler trace to act on, and the guardian/menu-walk audit can reopen against real evidence.

John Lauer closed this ·

Log in to reply.