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 bug report

macOS KiCad 10.0.7: pcbnew SIGSEGV in OPENGL_GAL::DrawPolyline (PCB_PAINTER::draw(ZONE)) right after kicad_apply_zone_plan commits

Drew Owens · ·closed by Colby Knox

adom-aiflow 0.2.20 · adom/core 4.15.3 · Adom Bridge 1.9.224 on macOS 26.3.1 (MacBook Air, Apple silicon), KiCad bridge plugin 0.11.1 · KiCad 10.0.7

What I did: adom-aiflow land pours sent kicad_apply_zone_plan with 13 zones to a 152 x 152 mm, 4-layer board open in pcbnew: one GND pour on F.Cu and B.Cu following the outline, and twelve 1.8 mm solid GND squares at priority 1. The board's own inner planes were loaded from the file.

What happened: the reply came back committed: true, drc.clean: true, zonesRefilled: true. Within seconds pcbnew crashed on the main thread during the repaint. It happened twice with the same stack, at 21:18 and 21:31 UTC on 2026-10-26 (the full macOS crash reports are available on request):

EXC_BAD_ACCESS SIGSEGV, faulting thread 0 (main)
libkigal  std::__function::__func<KIGFX::OPENGL_GAL::DrawPolyline(SHAPE_LINE_CHAIN const&)::$_0 ...
libkigal  KIGFX::OPENGL_GAL::drawPolyline(std::function<VECTOR2<double> (int)> const&, int, bool)
libkigal  KIGFX::OPENGL_GAL::DrawPolyline(SHAPE_LINE_CHAIN const&)
_pcbnew   KIGFX::PCB_PAINTER::draw(ZONE const*, int)
_pcbnew   KIGFX::PCB_PAINTER::Draw(KIGFX::VIEW_ITEM const*, int)
libkigal  KIGFX::VIEW::updateItemGeometry(KIGFX::VIEW_ITEM*, int)
libkigal  KIGFX::VIEW::invalidateItem(KIGFX::VIEW_ITEM*, int)
libkigal  KIGFX::VIEW::UpdateItems()
_pcbnew   EDA_DRAW_PANEL_GAL::DoRePaint(bool)

The zone-filler worker threads were idle at the crash. Before each landing, a kicad_zone_state refill of the two file-loaded planes went through without a crash. So the crash seems tied to zones created through the IPC API, not to filling in general. The same 13 zones written into the file and filled with kicad-cli pcb drc --refill-zones --save-board were fine.

Expected: no crash, or, if this is a KiCad bug in redrawing zones created over IPC, a note in kicad_apply_zone_plan's hint and an upstream KiCad report. I can rerun the landing on request to test a fix.

2 Replies

John Lauer ·

Thanks for the stack traces and the careful comparison (the same zones written to the file and filled by kicad-cli are fine). That narrows it a lot.

What the trace says. pcbnew dies inside KiCad's own OpenGL painter (PCB_PAINTER::draw(ZONE) drawing the zone's outline polyline) during the repaint after the zone plan committed. The bridge isn't running at that moment: the commit and the refill had already returned. So the crash is in KiCad, but something about the zones created through the API sets it off.

My leading suspect: the twelve 1.8 mm solid squares at priority 1. With your clearances and minimum width, a square that small can fill to a sliver or to nothing at all. KiCad's file loader and kicad-cli clean that up on load. A zone created live through the API keeps the empty or degenerate fill in memory, and the OpenGL painter on macOS then draws it. That would explain why the file route is fine and the live route is not.

Could you run these, so we know which zone does it?

  1. Land only the outline GND pour (F.Cu and B.Cu), no squares.
  2. Land only the twelve squares.
  3. Land the squares at 3 mm instead of 1.8 mm.

If (1) survives and (2) crashes, I'll add a guard to kicad_apply_zone_plan. It will compute each planned zone's fill before landing, refuse any zone that would fill to nothing or a sliver, and say which one and why. Then I'll report the crash to KiCad with a minimal board, since a zone with an empty fill should never crash the editor. Please attach one of the macOS crash reports here too, so I can include it upstream.

One note on your setup: the KiCad bridge on your Mac is our macOS port (0.11.1), a separate line from the native Windows and Linux build. The guard will land in both.

Colby Knox ·

kicad-lane: closing this as KiCad's own bug in its macOS OpenGL painter. I could not reproduce it on Windows.

What I ran today (Windows 11, KiCad 10.0.7, kicad-bridge 1.0.85): the same kind of plan landed live with kicad_apply_zone_plan on a 4-layer ESC board with inner planes, open in pcbnew:

  • one GND pour on F.Cu and B.Cu over the whole board, priority 0;
  • twelve 1.8 mm solid GND squares on F.Cu, priority 1, spread over the board.

All 13 zones committed and pcbnew repainted the board. It was still running 10 s later and after a capture that forced a redraw. I then closed the board without saving.

So the crash is in KiCad's macOS OpenGL path (OPENGL_GAL::DrawPolyline in PCB_PAINTER::draw(ZONE)), not in the plan: the bridge isn't running when the crash happens.

If it happens again on the Mac, please reopen this with:

  • one of the macOS crash reports;
  • which of John's three runs crashes (outline only, squares only, squares at 3 mm).

With those I'll file the crash with KiCad, with a minimal board. If the small squares turn out to be the trigger, I'll also add a guard to kicad_apply_zone_plan that refuses a zone that would fill to nothing.

Colby Knox closed this ·

Log in to reply.