## Description KiCad crashes with a null-pointer access violation in `LIB_BUFFER::GetDerivedSymbolNames` during interactive schematic editing (editing symbol fields). The crash is inside a SELECTION_TOOL coroutine while re-evaluating a conditional context-menu entry registered by SYMBOL_EDITOR_CONTROL. Stack (symbolized by @dsa-t from the dump attached to #24966, `kicad.exe.35752.zip`, 2026-07-09): ``` _eeschema!std::_Ptr_base<LIB_SYMBOL>::_Incref _eeschema!std::shared_ptr<LIB_SYMBOL>::{ctor} _eeschema!LIB_SYMBOL::SharedPtr _eeschema!LIB_BUFFER::GetDerivedSymbolNames _eeschema!SYMBOL_EDITOR_CONTROL::Init::__l5::<lambda_5>::operator() _eeschema!CONDITIONAL_MENU::Evaluate _eeschema!SELECTION_TOOL::UpdateMenu _eeschema!COROUTINE<int,TOOL_EVENT const &>::callerStub _eeschema!make_fcontext ``` WinDbg `!analyze -v` of the same dump: exception c0000005, read at 0x1C8 with `rax = 0` (`mov rcx, [rax+1C8h]`), i.e. a null `this`/object with a member access at offset 0x1C8. Fault address `_eeschema+0x7ABB5A`. `FAILURE_BUCKET_ID: NULL_CLASS_PTR_READ_c0000005__eeschema.dll!Unknown`. Process uptime at crash: 7h25m. Context: this was originally attached to #24966 (an IPC API crash) by mistake; the two turned out to be **distinct** null dereferences in `_eeschema.dll` (this one at `_eeschema+0x7ABB5A` in the tool-framework/menu path; the API one at `_eeschema+0x6cf2d` in `API_HANDLER_EDITOR::checkForBusy`, filed as #24966). Splitting per one-issue-per-report. I have two WER full dumps of this crash (2026-07-04 and 2026-07-09, both captured during symbol-field editing sessions). The 2026-07-09 dump is already attached to #24966; I can re-attach it here and/or provide the 2026-07-04 one if useful. ## Steps to reproduce I do not yet have a minimal reliable reproduction — the crash occurred twice during normal editing sessions on a hierarchical multi-channel project while adding/editing custom symbol fields ("Role") across many symbols. Both times on a long-running session. I will update with exact steps if I catch it again (first-chance ProcDump monitoring is now set up). 1. Open the attached project, open the Schematic Editor. 2. Edit custom fields on symbols across hierarchical sheets (exact trigger not yet isolated). ## KiCad Version ``` Application: KiCad x64 on x64 Version: 10.0.4, release build Libraries: wxWidgets 3.3.2 FreeType 2.13.3 HarfBuzz 12.3.0 FontConfig 2.17.1 libcurl/8.18.0 Schannel zlib/1.3.1 Platform: Windows 11 (сборка 26200), 64-бит редакция, 64 bit, Little endian, wxMSW Build Info: Date: Jun 20 2026 00:17:57 wxWidgets: 3.3.2 (wchar_t,STL containers) Boost: 1.90.0 OCC: 7.9.2 Curl: 8.18.0 ngspice: 46 Compiler: Visual C++ 1944 without C++ ABI KICAD_IPC_API=ON KICAD_USE_PCH=OFF Locale: Lang: ru_RU Enc: UTF-8 Num: 1 234,5 Encoded кΩ丈: D0BACEA9E4B888 (sys), D0BACEA9E4B888 (utf8) ``` ## Description Calling `Board.update_items()` from the IPC API (kicad-python / kipy 0.7.1) crashes the whole KiCad process with a null-pointer access violation in `API_HANDLER_EDITOR::checkForBusy()` (`common/api/api_handler_editor.cpp:207`), when: - the Schematic Editor is open in the session, and - no interactive edit has been made in the session yet. The call does not need to modify anything — echoing back a single unmodified footprint is enough. Read-only API calls (ping, get_version, get_open_documents, get_board, get_footprints, reading pads and fields) all work in the same session immediately before the crash. Fully symbolized stack from a first-chance ProcDump full dump (symbols from `SRV*https://symbols.kicad.org/kicad-stable`): ``` _eeschema!API_HANDLER_EDITOR::checkForBusy+0xd [common\api\api_handler_editor.cpp @ 207] <- fault: mov rax,[rcx] with rcx = 0 _eeschema!API_HANDLER_EDITOR::handleUpdateItems+0x34 [common\api\api_handler_editor.cpp @ 249] _eeschema!`API_HANDLER::registerHandler<kiapi::common::commands::UpdateItems,...>'::<lambda_1> [include\api\api_handler.h @ 112] kicommon!API_HANDLER::Handle+0x30a [common\api\api_handler.cpp @ 55] kicommon!KICAD_API_SERVER::handleApiEvent+0x594 [common\api\api_server.cpp @ 246] wx event loop ... wxAppConsoleBase::MainLoop -> APP_KICAD::OnRun ``` Exception c0000005, read at address 0x0 (`rcx = 0` at the fault site). Main thread, plain wx event dispatch. The board-targeted UpdateItems request is dispatched to **eeschema's** registered API handler, whose `checkForBusy()` dereferences a null pointer. Observed behavior consistent with the stack: - Schematic Editor never opened in the session → no crash (3/3 clean runs; presumably the eeschema handler is not registered). - Any interactive edit + save in pcbnew before the first API write → no crash for the rest of the session (presumably initializes whatever `checkForBusy()` dereferences). - Reproducibility correlates with cold start: on a freshly rebooted Windows it reproduces reliably; on a warmed-up system it becomes intermittent. A 30 s idle delay before the write does not help, and one crash occurred after 7h25m of process uptime — the vulnerable state is cured by an event (first interactive edit), not by time. - The exception escalates first-chance → second-chance (`Unhandled: C0000005`) and the process dies silently: no WER "Application Error" event, no crash dialog. The IPC pipe drops \~0.5 s after the request; the client gets `ConnectionError: Error receiving reply from KiCad: Timed out`. The originally attached dump (2026-07-09, `kicad.exe.35752.zip`) turned out to be a **different** null dereference captured during interactive schematic editing (`LIB_BUFFER::GetDerivedSymbolNames` via a SELECTION_TOOL coroutine, `_eeschema+0x7ABB5A`) — reported separately (see linked issue). The crash described here is at `_eeschema+0x6cf2d` on the API handler path. The full cdb `!analyze -v` output for the API crash is attached; the 4.6 GB first-chance full dump is available on request. ## Steps to reproduce Best chance to reproduce: freshly rebooted Windows, first KiCad session. Attached archived project can be used, but any project with a schematic and a PCB reproduces it. 1. Start KiCad, open the attached project. 2. Open the Schematic Editor and the PCB Editor. Do **not** edit or save anything. 3. Run against the running instance (`pip install kicad-python==0.7.1`): ```python from kipy import KiCad k = KiCad() board = k.get_board() fp = board.get_footprints()[0] board.update_items([fp]) # no-op echo of an unmodified footprint ``` 4. KiCad terminates within \~0.5 s. A more detailed diagnostic ladder (staged reads, then the fatal write, with liveness checks, PID monitoring and ms-timestamped logging) is available at: [diagnose_first_write_crash.py](https://github.com/GrandFatherPikhto/KiCadSpoke/blob/ad935c03fe4bc7643650fd1146183c37440f9f39/kicadspoke/diagnostics/diagnose_first_write_crash.py) ## KiCad Version ``` Application: KiCad x64 on x64 Version: 10.0.4, release build Libraries: wxWidgets 3.3.2 FreeType 2.13.3 HarfBuzz 12.3.0 FontConfig 2.17.1 libcurl/8.18.0 Schannel zlib/1.3.1 Platform: Windows 11 (сборка 26200), 64-бит редакция, 64 bit, Little endian, wxMSW Build Info: Date: Jun 20 2026 00:17:57 wxWidgets: 3.3.2 (wchar_t,STL containers) Boost: 1.90.0 OCC: 7.9.2 Curl: 8.18.0 ngspice: 46 Compiler: Visual C++ 1944 without C++ ABI KICAD_IPC_API=ON KICAD_USE_PCH=OFF Locale: Lang: ru_RU Enc: UTF-8 Num: 1 234,5 Encoded кΩ丈: D0BACEA9E4B888 (sys), D0BACEA9E4B888 (utf8) ```