I took over an old schematic with an already existing artwork and an existing zone.
I deleted in that schematic all the components and included my new circuit and generated the net-file.
After entering PCBNew, I loaded the new net-file.
And I was able to draw/fill zones without any problems.
BUT: in the moment I am deleting the OLD zone (which was a remain from the old schematic) PCBnew crashs immediately.
Can you post the
(zone (net … ) )
stuff from both the version that works and the one that doesn’t?
PS: the forum is run by a 3rd party to the KiCAD team. But it’s the best we got 
PPS: total dumb idea, but can you run a VM on your Arch Linux with maybe Ubuntu or something that might bring OpenGL relevant drivers (even if closed source) to see if that helps you?
Hmm… That sounds less data-base related and more OS/Build pairing related.
ie DEL of something that existed and fills ok, leaves just internal housekeeping , tho you would not think that code would be OS-specific in any way ?
Okay.
regarding the attached file:
I chose an existing schematic of mine, which also included a fill-zone and which didn’t result in any crashs.
In eeschema I deleted all the old components and generated a new net-file.
In PCBnew I uploaded that netfile arranged the new components and made a new zone, which I could also fill without any crash.
Next, I started to delete in PCBnew the traces and zones from the old artwork. This I did one-by-one, which means: I deleted one trace, did fill-zones, deleted the next trace, filled the zones etc. When I arrived at the very last trace and did the fill-zone, PCBnew crashs.
The attache files are:
Gesamtplatine.net: The netfile
Gesamtplatine.kicad_pcb: The PCBNew file, which still contains the very last trace from the old artwork (–> this does not crash, when doing a fill-zone).
Crashs.kicad_pcb: THE PCBnew file, from which also the very last trace of the old artwork is deleted. I saved this before doing the fill-zone command. This file crashed, after I did fill-zones, and also, when I try to open it in PCBnew, PCBnew crashs
One remark: PCBNew crashes ONLY, when the pop-up window “updating ratnest” appeared. And this pop-up window only comes up, when I have deleted the last trace from the old artwork.
Gesamtplatine.net (4.9 KB)
CRASHS.kicad_pcb (22.6 KB)Gesamtplatine.kicad_pcb (23.0 KB)
Okay. I think I am coming close to the problem/solution:
It seems, there must be at least one trace before filling zones.
Because: in the example above, I had not added any traces before doing fill-zones. Now I added one trace among the new components and deleted the very last remaining trace from the old artwork. And a fill-zone command is NOT crashing PCBnew.
Now, I think: this all had nothing to do with old or new schematics and artworks. Although nothing with the display mode. KiCAD simply needs to have one trace ahead of any fill-zone command.
The zone fill needs a track of the net the zone belongs to, to actually be able to fill the zone.
Without a track that goes into the zone where it should be filled, it wont fill it.
Seems you found some unstable behavior there with the zone fill tool for your OS.
Can you confirm that the crash definitely happens when you draw a zone that got no track in it of the same net the zone belongs to and then try to fill it?
Might be worth a big report then…
Let me make a fresh test-circuit. I will report in a couple of minutes.
What I did:
Started KiCad
Generated a new project test.pro
Started eeschema
Added the path to my symbol-liberary (you may not see the resistor in eeschema, since I used my own designed symbol
Added two resistors in serial and one global label V0
Annotated schematic
Run Cvpcb
Asigned footprint to the components and clicked “save”
Back in eeschema: generated netlist for PCBnew
Started PCBNnew
In PCBNew: Read current netlist
In PCBNew: moved the two resistors a bit appart. BUT did not add any traces
In PCBNew: clicked save; added fill-zone (selected the net V0 from the global label as a connection)
In PCBNew: saved as an additional pcb-file: with_EMPTY_ZONE.kicad_pcb
In PCBNew: right click in the zone --> fill or refill all zones
==> the pop-up window appears, with a progress-bar and the message “Update ratnest” and then it crashs.
Started KiCad again
In PCBNew: I added ONE trace … draw the fill-zone again … right-click: fill zones --> it works
test.zip (3.1 KB)
[ BTW: if this is really a bug, I would like to excuse for my “frustation attitude” above. I mean: I am a profiteer of such Open Source programs … where many programmers have volunteerly spend their time for. And such bugs happens of course.]
That does sound like the sort of context-trigger type bug I was trying to describe above.
I tried this on Win8 19 June build 6943,
I cannot break it…
Unrouted Trace inside the pour -> Pours & generates thermals
Routed Trace inside the pour -> Pours & generates thermals
Unrouted Trace outside the pour -> no fill done
Routed Trace outside the pour -> no fill done
Looks like my system’s rule is Fill-on-contains, and routed/unrouted is immaterial.
Then, I tried leaving the Pour dangling, I renamed the net in SCH and imported.
Strictly, this really should also rename the pour net, but it does not. (minor bug)
It gives this warning
Warning: Copper zone (net name ‘Net-(J1-Pad9)’): net has no pads connected.
… but still does not crash. (no fill)
Re-tag to new name -> Fills OK
Re-tag to invalid net (still in list) -> no fill, (no crash)
Save-reload does strip the ‘phantom’ net node.
Anyway, it sounds like you have a work-around for your OS-Build combination ?
Same here, I did a new design, no traces yet (some footprints with zone connected pads are in each copper layer though). Created zones, filling seems to trigger the bug. After that the file crashes pcbnew on each open.
Opening a text editor and manually removing all zone sections from the .kicad_pcb file allows opening it again.
I guess some error handling is missing in the zone filling code.
Which Build and OS did you use ?
(Arch) Linux AMD64 with BZR 6948 / Git 9a0d346. In other words, freshly built from Git a couple of hours ago. When I first encountered the issue the first thing I did was build a fresh copy to see if the problem persisted.
Did that fresh build include wxWidgets ?
I find info in the bugs area : https://bugs.launchpad.net/kicad/+bug/1595828
> Have you something like a warning message when running Kicad (try to run it from a console)?
_ Raynor Pettge (raynor-6) wrote 16 hours ago: #7_
_ Yes, running any of the KiCAD programs from the shell gives me:_
_ 18:30:28: Warning: Mismatch between the program and library build versions detected._
The library used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.8).
jean-pierre charras (jp-charras) wrote 15 hours ago: #8
Therefore you have a build issue.
It cannot be fixed in Kicad code.
It can be fixed only by rebuilding Kicad.
It looks like wxWidgets (the library) and the Kicad binaries are built with different compilers, or Kicad was compiled with a different wxWidgets version than your installed version.
As long as you have this message You’ll have issues.
Interesting, you are correct, running from a shell I indeed get this warning:
The library used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.8)
I am using the system wxWidgets libraries and my compile options do differ from Arch defaults (updated GCC, march=native and linktime optimisation enabled.
I’ll fetch wxgtk-git, build that, build KiCad against it and see if that fixes the issue.
So I rebuilt WxWidgets and KiCad. The ABI mismatch is fixed now.
As for the bug: Doing a global tracks delete instantly segfaults KiCad (no further error message in the shell output).
Like I said before: It looks more like a combination of a bug in the zone filling code and missing error handling for this in the KiCad source than anything GUI toolkit related.
An update on this bug: For me this only happens with release builds. I was wondering if the other people experiencing this bugs are using Arch Linux as well?
Can you update the Bug thread with your findings ?
I’m unclear in all of this if a new build solves this, or of there is some regression in Arch Linux ?
Already have. It could be a library, or perhaps an interaction with the very recent GCC version.
Can you run this for me?
pacman -Q | egrep -i "^(boost|cairo|cmake|freeglut|gcc|glew|glm|python |wxgtk|wxpython|zlib)"
This produces a list of installed library versions used by KiCad:
boost 1.60.0-5
boost-libs 1.60.0-5
cairo-infinality-ultimate-with-colored-emoji 1.14.6-1
cairomm 1.12.0-2
cmake 3.5.2-2
freeglut 3.0.0-1
gcc-fortran 6.1.1-2
gcc-libs-multilib 6.1.1-2
gcc-multilib 6.1.1-2
glew 1.13.0-1
glm 0.9.7.5-1
python 3.5.1-2
wxgtk-git r61671.967bdbf-4
zlib 1.2.8-4
Perhaps we can find a pattern. If we collect some versions I’ll update the bug thread again.