pcbnew and footprint editor crashes when starting

[Rainer]

Problem: KiCAD pcbnew and footprint editor crashes when starting

Reproducibilry: always

Steps to reproduce: Start KiCAD -> start pcbnew or pcb fotprint editor

I use a self compiled version of KiCAD. I also tried the latest precompiled version from ftp://penguintown.net/debian/dists/jessie/main/binary-amd64/ which are made by http://gglabs.us/node/577 but it do have the same crash problem.

I configure KiCAD with the following commandline:
cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON ../

When i start kicad normally from commandline or with gdb it crashes at the same point. When starting with valgrind it doesn't crash at the same point.

I attached a log file from gdb and valgrind (where i started pcbnew directly on commandline). For the log files i compiled another version with the following commandline to get more debug output:
cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Debug ../

System information:
Debian Jessie (8) with Kernel 4.5.0 x86_64

Application: kicad
Version: (2016-05-05 BZR 6775, Git 08b5213)-product, release build
Libraries: wxWidgets 3.0.2
           libcurl/7.38.0 OpenSSL/1.0.1k zlib/1.2.8 libidn/1.29 libssh2/1.4.3 librtmp/2.3
Platform: Linux 4.5.0 x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.55.0
Curl: 7.38.0
KiCad - Compiler: GCC 4.9.2 with C++ ABI 1002
        Settings: USE_WX_GRAPHICS_CONTEXT=OFF
                  USE_WX_OVERLAY=OFF
                  KICAD_SCRIPTING=ON
                  KICAD_SCRIPTING_MODULES=ON
                  KICAD_SCRIPTING_WXPYTHON=ON
                  USE_FP_LIB_TABLE=HARD_CODED_ON
                  BUILD_GITHUB_PLUGIN=ON

[Maciej Suminski (orsonmmz)]

Hi Rainer,

Thank you for the report and backtrace. I am unable to recreate the problem on any available machine, so I just applied a blind patch (revision 6781). Could you verify if it helps?

Thank you in advance,
Orson

[Rainer (rwahler)]

It seems to work now. I can start pcbnew and the footprint editor without crashing anymore.

[Rainer (rwahler)]

Hmm there seems to be something strange.

Now when i compile KiCAD with
cmake -DCMAKE_INSTALL_PREFIX=/usr/local ../
it compiles and runs fine.

But when i compile it with python scripting support
cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON ../
the compilation aborts with an error.

The last messages before the compilation abort were:
/home/quakeman/Dokumente/sourcecode/kicad/kicad-git/pcbnew/../polygon/PolyLine.h:119: Warning 389: operator[] ignored (consider using %extend)
/home/quakeman/Dokumente/sourcecode/kicad/kicad-git/pcbnew/../include/utf8.h:209: Warning 325: Nested class not currently supported (uni_iter ignored)
/home/quakeman/Dokumente/sourcecode/kicad/kicad-git/pcbnew/class_module.h:241: Error: Syntax error in input(3).
pcbnew/CMakeFiles/_pcbnew.dir/build.make:53: recipe for target 'pcbnew/pcbnewPYTHON_wrap.cxx' failed
make[2]: *** [pcbnew/pcbnewPYTHON_wrap.cxx] Error 1
CMakeFiles/Makefile2:1347: recipe for target 'pcbnew/CMakeFiles/_pcbnew.dir/all' failed
make[1]: *** [pcbnew/CMakeFiles/_pcbnew.dir/all] Error 2
Makefile:137: recipe for target 'all' failed
make: *** [all] Error 2

I don't know if this has something to do with your latest changes but it's strange that only with scripting enabled it aborts now.

[jean-pierre charras (jp-charras)]

pcbnewPYTHON_wrap.cxx is created and compiled only if scripting is enabled.
There are always a few warnings. they do not create problems.

However, generally speaking, when you get an error when compiling pcbnewPYTHON_wrap.cxx, just delete this file, and retry compiling.
Usually errors are fixed.

[Rainer (rwahler)]

Interestingly i don't have the file pcbnewPYTHON_wrap.cxx at all anywhere within the kicad source or build directory. Could it be that it only exists temporarily while compiling?

[Maciej Suminski (orsonmmz)]

I have just compiled KiCad with scripting enabled without any problems (revision 6784).
You should have pcbnew_wrap.cxx and pcbnewPYTHON_wrap.cxx in build/pcbnew directory.

[Maciej Suminski (orsonmmz)]

Regarding the second question: the files stay there once a build is finished.

[Rainer (rwahler)]

Ok i understand what you are saying, but i don't have this file at all anywhere.
I will try to clean my build directory and do a fresh build with scripting enabled.

[Rainer (rwahler)]

Now i did the following steps and it fails again:
quakeman@fox-mulder:~/Dokumente/sourcecode/kicad/kicad-git/build$ rm -Rf *
quakeman@fox-mulder:~/Dokumente/sourcecode/kicad/kicad-git/build$ cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON ../
quakeman@fox-mulder:~/Dokumente/sourcecode/kicad/kicad-git/build$ make

The compilation aborted again with the following error:
/home/quakeman/Dokumente/sourcecode/kicad/kicad-git/pcbnew/../polygon/PolyLine.h:119: Warning 389: operator[] ignored (consider using %extend)
/home/quakeman/Dokumente/sourcecode/kicad/kicad-git/pcbnew/../include/utf8.h:209: Warning 325: Nested class not currently supported (uni_iter ignored)
/home/quakeman/Dokumente/sourcecode/kicad/kicad-git/pcbnew/class_module.h:241: Error: Syntax error in input(3).
pcbnew/CMakeFiles/_pcbnew.dir/build.make:53: recipe for target 'pcbnew/pcbnewPYTHON_wrap.cxx' failed
make[2]: *** [pcbnew/pcbnewPYTHON_wrap.cxx] Error 1
CMakeFiles/Makefile2:1347: recipe for target 'pcbnew/CMakeFiles/_pcbnew.dir/all' failed
make[1]: *** [pcbnew/CMakeFiles/_pcbnew.dir/all] Error 2
Makefile:137: recipe for target 'all' failed
make: *** [all] Error 2

And when i search for this file i can't find it anywhere and
quakeman@fox-mulder:~/Dokumente/sourcecode/kicad/kicad-git$ find . -iname 'pcbnewPYTHON_wrap.cxx'
returns no result.

[jean-pierre charras (jp-charras)]

@Orson:
I have the same issue in Kubuntu 14.04 LTS: the c++11 qualifier "override" (added recently in class_track.h and class_module.h at 2 functions) is not accepted (by swig, i am guessing) and pcbnewPYTHON_wrap.cxx is not created.
It could be worth to not use yet this qualifier.
I had to remove them to build Kicad.

@Rainer
What is your version of gcc (gcc -v) and swig (swig -version)?

mine are 4.8.4 and 2.11

I do not have this issue on msys2 (with a more recent compiler and swig)

[Maciej Suminski (orsonmmz)]

I see, I have just commented them out - thank you for the suggestion.
It works fine with gcc 5.3.0 and swig 3.0.8.

[Wayne Stambaugh (stambaughw)]

I guess this means no c++11 until we confirm the swig issues.
Otherwise, we will not be able to provide python scripting. Is there a
version of swig that can handle the c++11 override keyword? If so, we
should set the swig version in the cmake find swig. If not, no c++11
until it's fixed in swig.

On 5/10/2016 8:36 AM, Maciej Sumiński wrote:
> I see, I have just commented them out - thank you for the suggestion.
> It works fine with gcc 5.3.0 and swig 3.0.8.
>

[Maciej Suminski (orsonmmz)]

Looking at [1] I think a safe bet is swig 3.0.

1. http://swig.org/Doc3.0/CPlusPlus11.html

[Wayne Stambaugh (stambaughw)]

I just was looking at this. I'll change it to swig 3.0 so that we can
start using c+11. Otherwise there will be a bunch of build error bug
reports. I'm guessing there will be some grumbling about the change but
if we don't draw a line in the sand, we'll never get to c++11.

On 5/10/2016 9:37 AM, Maciej Sumiński wrote:
> Looking at [1] I think a safe bet is swig 3.0.
>
> 1. http://swig.org/Doc3.0/CPlusPlus11.html
>

[Rainer (rwahler)]

In debian 8 Jessie the default gcc version is 4.9.2 and swig is 2.0.12. But i see that i can additionally install swig 3.0.2 from the repositories.

[Rainer (rwahler)]

But it seems that cmake doesn't find swig3 here on debian. I installed it swig3 and removed swig2 and cmake complained about missing swig. After i reinstalled swig2 (now both versions installed) cmake finds swig and uses version 2.

[Wayne Stambaugh (stambaughw)]

What is the output when you run `which swig`? You may have to use
update-alternatives to set the correct version of swig as your default.
I just checked FindSWIG.cmake in version 3.4 of cmake and it searches
for swig, swig3.0, and swig2.0 executable names. If Debian is naming
them something different, way may have to provide a custom FindSWIG.cmake.

On 5/10/2016 9:59 AM, Rainer wrote:
> But it seems that cmake doesn't find swig3 here on debian. I installed
> it swig3 and removed swig2 and cmake complained about missing swig.
> After i reinstalled swig2 (now both versions installed) cmake finds swig
> and uses version 2.
>

[Maciej Suminski (orsonmmz)]

I am afraid Debian simply uses an old version of cmake that was built when swig3.0 did not exist. Check if /usr/share/cmakeXXX/Modules/FindSWIG.cmake has any traces of 'swig3.0'.

[Rainer (rwahler)]

The symlink /usr/bin/swig goes to /usr/bin/swig2.0. There also exists /usr/bin/swig3.0.
Debian uses cmake 3.0.2 and in /usr/share/cmake3.0/Modules/FindSWIG.cmake only swig 2.0 is referenced.

So maybe i could change the symlink from /usr/bin/swig to swig3.0 or i could add swig3.0 to FindSWIG.cmake if this helps. update-alternatives seems to not know swig.

[Wayne Stambaugh (stambaughw)]

Is "swig" (without version) in the list of executable names in your
FindSWIG.cmake? If so, you will have to change your /usr/bin/swig
symlink to link to swig3.0. If not and the only executable name is
swig2.0 than your options are less than ideal. You could also try
setting -DSWIG_EXECUTABLE=/usr/src/swig3.0 when you run cmake to
configure the kicad build.

On 5/10/2016 10:23 AM, Rainer wrote:
> The symlink /usr/bin/swig goes to /usr/bin/swig2.0. There also exists /usr/bin/swig3.0.
> Debian uses cmake 3.0.2 and in /usr/share/cmake3.0/Modules/FindSWIG.cmake only swig 2.0 is referenced.
>
> So maybe i could change the symlink from /usr/bin/swig to swig3.0 or i
> could add swig3.0 to FindSWIG.cmake if this helps. update-alternatives
> seems to not know swig.
>

[Wayne Stambaugh (stambaughw)]

CMake 3.0.2 is the version in Jessie. I'm not sure what executable
names FindSWIG.cmake checks for in CMake 3.0.2. Someone will have to
look that up for themselves and make sure that they match the version of
SWIG. It's possible Debian named

On 5/10/2016 10:16 AM, Maciej Sumiński wrote:
> I am afraid Debian simply uses an old version of cmake that was built
> when swig3.0 did not exist. Check if
> /usr/share/cmakeXXX/Modules/FindSWIG.cmake has any traces of 'swig3.0'.
>

[Rainer (rwahler)]

There exists /usr/bin/swig, /usr/bin/swig2.0 and /usr/bin/swig3.0 where swig is a symlink to swig2.0.
FindSWIG.cmake searches only for swig and swig2.0.

With the latest commit 6787 KiCAD compiles without problems with swig 2.0 and no changes.

[Maciej Suminski (orsonmmz)]

Yes, but the mentioned commit removes a keyword offered by C++11. As our goal is to transition to the new standard, we are likely going to require swig3.0 soon.

[Wayne Stambaugh (stambaughw)]

On 5/10/2016 11:01 AM, Rainer wrote:
> There exists /usr/bin/swig, /usr/bin/swig2.0 and /usr/bin/swig3.0 where swig is a symlink to swig2.0.
> FindSWIG.cmake searches only for swig and swig2.0.

If the search order is swig then swig2.0, you need to change your
/usr/bin/swig symlink to point to /usr/bin/swig3.0.

>
> With the latest commit 6787 KiCAD compiles without problems with swig
> 2.0 and no changes.
>

Don't expect this to continue. We are getting ready to begin migrating
towards c++11 so you will have to change your symlink if you want to
continue build the development version of kicad. We've held off on this
long enough. I'm going to set the minimum swig version to 3.0 soon so
the cmake configuration will fail if swig 3.0 or greater cannot be
found. The stable version will build just fine with swig 2.0 so you may
have to make a decision in that regard.

[Rainer (rwahler)]

I changed the symlink of /usr/bin/swig to /usr/bin/swig3.0 but cmake still uses swig2.0 as executable.
After a look at FindSWIG.cmake i see that it first searches for swig2.0 and then for swig. So i changed the symlink back to swig2.0 and added swig3.0 as first search field to FindSWIG.cmake and now cmake finds swig3.0. Now i will try to compile KiCAD with swig3.0 and hope all goes through. :)

[Wayne Stambaugh (stambaughw)]

This is an ugly hack. Using a symlink named swig2.0 to link to swig3.0
is really confusing.

If this is the case, then FindSWIG.cmake is broken. The search order
should be swig, swig3.0, swig2.0, ... Looking at how FindSWIG.cmake
searches for the executable file name, I'm not sure even setting
SWIG_EXECUTABLE will work which is completely wrong. You should always
be able to override the default executable name by passing a definition
on the command line or setting an environment variable. Many of the
cmake find macros suffer from this problem.

On 5/10/2016 11:31 AM, Rainer wrote:
> I changed the symlink of /usr/bin/swig to /usr/bin/swig3.0 but cmake still uses swig2.0 as executable.
> After a look at FindSWIG.cmake i see that it first searches for swig2.0 and then for swig. So i changed the symlink back to swig2.0 and added swig3.0 as first search field to FindSWIG.cmake and now cmake finds swig3.0. Now i will try to compile KiCAD with swig3.0 and hope all goes through. :)
>

[Rainer (rwahler)]

At the moment i doesn't change the symlink at all on the disk. So /usr/bin/swig points to /usr/bin/swig2.0 and isn't modified from the default setup. The only thing i changed was the search order in FindSWIG.cmake. Before it was "swig2.0 swig" and now it is "swig3.0 swig2.0 swig". You are right that the search order of "swig swig3.0 swig2.0" would be better but than i have to change the symlink too.

The compilation worked with swig2.0 and with swig3.0 without problems. So i think the bug can be closed.

[Maciej Suminski (orsonmmz)]

Try adding -DSWIG_EXECUTABLE=/usr/bin/swig3.0 to your cmake line used to
build KiCad.

[Romain Deterre (rdeterre)]

Hello,

I'm not sure if what I'm seeing is exactly the same problem, but KiCad PCB footprint editor crashes on two different Fedora 23 systems that use the nouveau driver for nVidia cards (GT650M and GT730).

I've attached the console output of KiCad when the PCB footprint editor freezes. Sometimes, the whole system freezes with weird video artifacts. Sometimes, it is possible to kill KiCad before the system freeze, and the system will run for a few more minutes before quitting.

[Romain Deterre (rdeterre)]

Sorry, I clicked 'post' before finishing writing the last message.

The KiCad version I use is the latest nighly build from mangelajo's copr (https://copr.fedorainfracloud.org/coprs/mangelajo/kicad/) : 1000:6832-nightlies.fc23

Also, starting the PCB footprint editor in 'Legacy' mode does not make the system misbehave. Lastly, pcbnew does not cause problems, even in 'OpenGL' mode.

[Bernhard Schneider (bernh5rd)]

Gentlemen,

I suspect there is a missing rpath.

My quick fix so far:

user@host:/opt/kicad/lib$ LD_LIBRARY_PATH=$PWD ../bin/kicad

[Mark J. Blair (nf6x)]

I believe that I am having this same issue. When I build kicad from source with scripting support enabled, it crashes with a segmentation fault when I try to launch pcbnew or the footprint editor. I have version 2016-08-24 BZR 7090, Git 532a5fb. I'm building and running it on Ubuntu 14.04 LTS. I use 4.0.3..stable daily for real work on the same system. The quick fix that bernh5rd suggested does not correct the issue for me.

[Nick Østergaard (nickoe)]

@Mark, did you 'make install' it or just running it directly?

[Mark J. Blair (nf6x)]

I have been doing a "make install". I just tried cd-ing into .../build/pcbnew and executing pcbnew, and that dumps core with a segmentation fault.

[Mark J. Blair (nf6x)]

I don't know if this will be helpful or not. I re-compiled as a Debug type build with this cmake invocation:

  cmake -DCMAKE_BUILD_TYPE=Debug \
        -DKICAD_SCRIPTING=ON \
        -DKICAD_SCRIPTING_MODULES=ON \
        -DKICAD_SCRIPTING_WXPYTHON=ON \
        ../

When I launch pcbnew out of the build/pcbnew directory, it crashes thusly:

~...build/pcbnew% ./pcbnew
04:34:15 PM: Debug: kiface SEARCH_STACK:
04:34:15 PM: Debug: [ 0]:/usr/local/share/kicad/template
04:34:15 PM: Debug: [ 1]:/home/mblair/src/kicad/build/template
04:34:15 PM: Debug: [ 2]:/usr/share/kicad/modules
04:34:15 PM: Debug: [ 3]:/usr/share/kicad/modules/packages3d
04:34:15 PM: Debug: [ 4]:/usr/share/kicad/template
04:34:15 PM: Debug: [ 5]:/usr/local/share
./src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" failed in Register(): Class "wxCommandEvent" already in RTTI table - have you used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
./src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" failed in Register(): Class "wxNotifyEvent" already in RTTI table - have you used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
./src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" failed in Register(): Class "wxScrollEvent" already in RTTI table - have you used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
{... many dozens of similar assertions ...}
./src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" failed in Register(): Class "wxSimpleHtmlListBox" already in RTTI table - have you used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
Segmentation fault (core dumped)

[Nick Østergaard (nickoe)]

Please provide a backtrace of that instead.

[Nick Østergaard (nickoe)]

And remember you are not supposed to run it from the build directory.

[Mark J. Blair (nf6x)]

Ok, I'll try to figure out how to get a backtrace of it tomorrow at work. Can I do that by launching pcbnew in gdb from within pcbnew's install directory?

[Mark J. Blair (nf6x)]

Is this what you need?

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff72d70a4 in wxStatusBarPaneArray::RemoveAt(unsigned long, unsigned long) () from /usr/local/lib/libwx_gtk3u_core-3.0.so.0
(gdb) bt
#0 0x00007ffff72d70a4 in wxStatusBarPaneArray::RemoveAt(unsigned long, unsigned long) () from /usr/local/lib/libwx_gtk3u_core-3.0.so.0
#1 0x00007ffff72d7692 in wxStatusBarBase::SetFieldsCount(int, int const*) ()
   from /usr/local/lib/libwx_gtk3u_core-3.0.so.0
#2 0x00007ffff71c80f6 in wxStatusBar::Create(wxWindow*, int, long, wxString const&) () from /usr/local/lib/libwx_gtk3u_core-3.0.so.0
#3 0x00007ffff7268aaf in wxFrameBase::OnCreateStatusBar(int, long, int, wxString const&) () from /usr/local/lib/libwx_gtk3u_core-3.0.so.0
#4 0x00007ffff7268698 in wxFrameBase::CreateStatusBar(int, long, int, wxString const&) () from /usr/local/lib/libwx_gtk3u_core-3.0.so.0
#5 0x00007fffdf22f0e6 in EDA_DRAW_FRAME::EDA_DRAW_FRAME (this=0x2384a50,
    aKiway=0x67f700 <Kiway>, aParent=0x0, aFrameType=FRAME_PCB, aTitle=...,
    aPos=..., aSize=..., aStyle=541335104, aFrameName=...)
    at /home/mblair/src/kicad/common/draw_frame.cpp:165
#6 0x00007fffdf01428d in PCB_BASE_FRAME::PCB_BASE_FRAME (this=0x2384a50,
    aKiway=0x67f700 <Kiway>, aParent=0x0, aFrameType=FRAME_PCB, aTitle=...,
    aPos=..., aSize=..., aStyle=541335104, aFrameName=...)
    at /home/mblair/src/kicad/pcbnew/basepcbframe.cpp:97
#7 0x00007fffde92e560 in PCB_BASE_EDIT_FRAME::PCB_BASE_EDIT_FRAME (this=
    0x2384a50, aKiway=0x67f700 <Kiway>, aParent=0x0, aFrameType=FRAME_PCB,
    aTitle=..., aPos=..., aSize=..., aStyle=541335104, aFrameName=...)
    at /home/mblair/src/kicad/pcbnew/./pcb_base_edit_frame.h:40
#8 0x00007fffde924c37 in PCB_EDIT_FRAME::PCB_EDIT_FRAME (this=0x2384a50,
---Type <return> to continue, or q <return> to quit---
    aKiway=0x67f700 <Kiway>, aParent=0x0)
    at /home/mblair/src/kicad/pcbnew/pcbframe.cpp:315
#9 0x00007fffde8fc0c6 in PCB::IFACE::CreateWindow (
    this=0x7fffdffee500 <PCB::kiface>, aParent=0x0, aClassId=5,
    aKiway=0x67f700 <Kiway>, aCtlBits=1)
    at /home/mblair/src/kicad/pcbnew/pcbnew.cpp:118
#10 0x000000000042ab15 in KIWAY::Player (this=0x67f700 <Kiway>,
    aFrameType=FRAME_PCB, doCreate=true, aParent=0x0)
    at /home/mblair/src/kicad/common/kiway.cpp:326
#11 0x0000000000420558 in PGM_SINGLE_TOP::OnPgmInit (this=0x67f960 <program>,
    aWxApp=0x6d4f10) at /home/mblair/src/kicad/common/single_top.cpp:210
#12 0x0000000000423781 in APP_SINGLE_TOP::OnInit (this=0x6d4f10)
    at /home/mblair/src/kicad/common/single_top.cpp:100
#13 0x0000000000422271 in wxAppConsoleBase::CallOnInit (this=0x6d4f10)
    at /usr/local/include/wx-3.0/wx/app.h:93
#14 0x00007ffff6b6963c in wxEntry(int&, wchar_t**) ()
   from /usr/local/lib/libwx_baseu-3.0.so.0
#15 0x0000000000420344 in main (argc=1, argv=0x7fffffffe398)
    at /home/mblair/src/kicad/common/single_top.cpp:174
(gdb)

[Alex (ajhanson)]

I would like to report that KiCad 4.0.4 crashes on Windows 10 64-bit when trying to open Pcbnew. I would be happy to provide any error data if you can tell me what you need.

[Nick Østergaard (nickoe)]

@Alex, please test the latest nightly.