Closed bug report

kicad_close ends with forceKilled:[pcbnew.exe] after the graceful pass (winvm 0.9.340, KiCad 10.0.6)

John Lauer · ·closed by John Lauer

From Codex's clean-install run on winvm (issue #81 thread): kicad_close {} closed three windows and reported success, but data.forceKilled lists pcbnew.exe, so the PCB editor did not exit on the graceful path within the wait and was terminated. Evidence: https://wiki.adom.inc/attachments/adom/kicad-bridge/674e542790b9a158d0b8c6cee9e661832adf1b7f4a6458e3632646b2bce1c819/winvm-fresh-cleanup.json (durationMs 7605). To check: whether pcbnew was answering a save prompt or the OpenGL fallback at the time, whether the graceful wait is long enough on a software-rendering VM, and whether a forced kill can leave the fp-info-cache or the project lock file behind. Not a data-loss report: the fixture was disposable and unsaved edits were expected to be discarded.

1 Reply

John Lauer ·

Fixed in insiders 0.9.347 (zip sha256 a266ae4e3eb16a4ee033b86ff2f1437e79550d63854287b471f928eb4fb53f8e). kicad_close no longer force-kills an editor that is asking to save. Measured on arav-rog with a dirty fixture board: kicad_close {} now returns success:false, errorCode unsaved_changes, with the dialog text (Save Changes? / Save changes to live-routing.kicad_pcb before closing?) and the window left open; kicad_close {"discardChanges":true} presses Discard (Win32 click on the dialog button, UIA fallback) and the close completes gracefully with no forceKilled; force:true remains the only kill. The graceful wait per window is 8 s (was 5 s). Documented in SKILL.md (package 1.0.131). The stray lock-file question from the report is answered by the same change: nothing is killed unless asked, so KiCad releases its lock itself.

John Lauer closed this ·

Log in to reply.