KiCad r11526 crashes during eagle import

[Bob]

While trying to import an eagle project into KiCad r11526 (tried r11482 as well), some files are created but KiCad crashes after a few seconds and no sch or pcb file is created.

I have the following files:

empty.kicad_wks file,
eagle_project_name.pro
eagle_project_name-eagle-import.
eagle_project_name-eagle-import.lib
sym-lib-table

Same project could be imported with KiCad v5.0.0 but I had some warnings because of restrict Layers and some warnings because of polygons/rectangles on copper layers.

I found this bug report:
https://bugs.launchpad.net/kicad/+bug/1755886
and thought it might be a good idea to try a nightly build since the bug is marked as fixed.

Seems that it might be another issue or something special with my eagle files?

Version info:

Application: kicad
Version: (6.0.0-rc1-dev-911-g0777d1118), release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.54.1
    Compiler: GCC 7.1.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

Best regards,
Bob

[Nick Østergaard (nickoe)]

This is possibly a duplicate of
https://bugs.launchpad.net/kicad/+bug/1797701

[Wayne Stambaugh (stambaughw)]

I know Seth reverted the original change that caused this bug in the 5.0 branch but I just took a quick look in the development branch log and I didn't see the same change so maybe he forgot to revert it in the dev branch.

[Seth Hillbrand (sethh)]

Forgot to push sorry! Should be in now.

[Bob (b-ansay)]

Sorry if this is a nonsense question:

Does this mean it is now available in some nightly build for me to test?

Cheers,
Bob

[Bob (b-ansay)]

I tried r11552, this version also crashes

[Nick Østergaard (nickoe)]

I guess you are testing on windows not with kicad-r11552.c22a247db-x86_64.exe, this should contain the fix as far as I can see. @Seth, are you able to check this again?

[Bob (b-ansay)]

Yes, I am on windows

this is the version info of the one I used for the test today:

Application: kicad
Version: (6.0.0-rc1-dev-937-gc22a247db), release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.54.1
    Compiler: GCC 7.1.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Bob (b-ansay)]

If it helps, I can give you my eagle files, but don't like to post them on here...

[Seth Hillbrand (sethh)]

@Bob- Can you send your files to me directly please? My contact info is available by clicking on my name next to this message.

[Wayne Stambaugh (stambaughw)]

I confirmed this on windows (6.0.0-rc1-dev-949-gc06e53368) using one of the arduino reference designs which I have included for verification. I also confirmed that it crashes using 5.0.1 (downloaded from the website) and HEAD of the 5.0 branch as well so this is a major regression because I've used this eagle project in the past for testing purposes without issues. Here is the really fun part, all of the crashes above were release builds. 64 bit debug builds work fine. 32 bit debug builds crash. I'm not sure if this a bug with kicad or the msys2/mingw build tool chain. Does anyone have a msvc build that we can test to confirm this theory?

[Seth Hillbrand (sethh)]

Oh good. This one sounds like fun. :)

[Seth Hillbrand (sethh)]

Hmm... This does not recreate on Linux.

Tested 64-bit, debug and release for 5.1 head (ga5c892d9c) and 5.0.2 head

Also checked for memory allocation/access errors but did not see anything suspicious.

Is this perhaps Windows-specific? Wayne, can you share the MS system log info for when this happens?

[Wayne Stambaugh (stambaughw)]

Maybe it wont be so bad. I just installed 5.0.0 (64-bit) from the website and it works fine so we should be able to do a git bisect of the 5.0 branch to figure out where things went sideways. I'm in the process of checking out the 32 bit installer to see if that works as well.

[jean-pierre charras (jp-charras)]

On my W7 32 bit install, the import of arduino-mega2560_R3-reference-design works fine, both with 5.01 and 5.1 versions.

[Wayne Stambaugh (stambaughw)]

The system event error was:

Faulting application name: kicad.exe, version: 0.0.0.0, time stamp:
0x5bc89ae6
Faulting module name: libstdc++-6.dll, version: 0.0.0.0, time stamp:
0x00000000
Exception code: 0x40000015
Fault offset: 0x0001f71f
Faulting process id: 0x6cc
Faulting application start time: 0x01d466f07c80cb1d

I'm not sure this is very helpful. If you need anything else, please
let me know. I may not be able to reply immediately as I have a rather
busy afternoon. I should be able to work on this some more tomorrow.

On 10/18/2018 12:21 PM, Seth Hillbrand wrote:
> Hmm... This does not recreate on Linux.
>
> Tested 64-bit, debug and release for 5.1 head (ga5c892d9c) and 5.0.2
> head
>
> Also checked for memory allocation/access errors but did not see
> anything suspicious.
>
> Is this perhaps Windows-specific? Wayne, can you share the MS system
> log info for when this happens?
>

[Wayne Stambaugh (stambaughw)]

Just out of curiosity, what version of boost are building with?

On 10/18/2018 12:49 PM, jean-pierre charras wrote:
> On my W7 32 bit install, the import of arduino-mega2560_R3-reference-
> design works fine, both with 5.01 and 5.1 versions.
>

[jean-pierre charras (jp-charras)]

Boost 1.63.

here is the full info:

Application: kicad
Version: (6.0.0-rc1-dev-949-gc06e53368), release build
Libraries:
    wxWidgets 3.1.1
    libcurl/7.50.3 OpenSSL/1.0.2j zlib/1.2.8 libidn/1.33 libssh2/1.7.0 nghttp2/1.15.0 librtmp/2.3
Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.1.1 (wchar_t,wx containers)
    Boost: 1.63.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.53.1
    Compiler: GCC 6.3.0 with C++ ABI 1010

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Seth Hillbrand (sethh)]

@JP- Does the stock installer from the website work for you as well? Or only your compiled build?

[jean-pierre charras (jp-charras)]

Website version 5.1 works, and 5.01-3 crashes.

I am thinking the 5.01-3 is too old and does not contains the fix:
commit e34dc4a: Revert "pcbnew: Fix memory leak in Eagle importer"

My local build is 5.01-7 and was built after this commit.
The build 5.01-9 also works fine.

[Nick Østergaard (nickoe)]

Hello JP,

your comment in #20 is ambiguous. I never built at 5.1 for windows, and neither a 5.0.1-9 or 5.0.1-7. I think you need to clarify exactly what you are referring to here.

[jean-pierre charras (jp-charras)]

Hi Nick,

Website version 5.1 is the last nightly (I could be called it 6.0).
(http://downloads.kicad-pcb.org/windows/nightly/kicad-r11565.a5c892d9c-i686.exe)

5.0.1-9 or 5.0.1-7 are my local builds.

Stable website version 5.01-3 do not have the import eagle bug fixed (it was fixed in 5.01.5

[Nick Østergaard (nickoe)]

The tip of the 5.0 branch is built and uploaded at
http://downloads.kicad-pcb.org/windows/testing/5.0

[Wayne Stambaugh (stambaughw)]

I figured out my issue and I suspect it is the same issue for the windows packages. Apparently the msys2 project made a bad binutils release for mingw32 and mingw64 and a bad release of gcc 7.3.0 on mingw32 which they pulled from the packages list once they discovered this issue. Unfortunately, if you upgraded during this should period, you have the broken packages installed. Once I down graded these packages using `pacman -Syuu` and rebuilt kicad, the bug is resolved. Would our windows package dev please check if this is the case for our windows builders? Below is the output from pacman when I performed the downgrade so you should be able to check the builder setup to see if the offending packages are installed on the builder.

warning: mingw-w64-i686-binutils: downgrading from version 2.31.1-2 to version 2.30-5
warning: mingw-w64-i686-gcc: downgrading from version 7.3.0-3 to version 7.3.0-2
warning: mingw-w64-i686-gcc-ada: downgrading from version 7.3.0-3 to version 7.3.0-2
warning: mingw-w64-i686-gcc-fortran: downgrading from version 7.3.0-3 to version 7.3.0-2
warning: mingw-w64-i686-gcc-libgfortran: downgrading from version 7.3.0-3 to version 7.3.0-2
warning: mingw-w64-i686-gcc-libs: downgrading from version 7.3.0-3 to version 7.3.0-2
warning: mingw-w64-i686-gcc-objc: downgrading from version 7.3.0-3 to version 7.3.0-2
warning: mingw-w64-x86_64-binutils: downgrading from version 2.31.1-2 to version 2.30-5

[Wayne Stambaugh (stambaughw)]

@Nick, do you what versions of gcc and binutils are used to build our windows packages?

[Nick Østergaard (nickoe)]

These are the packages on the builder:
mingw-w64-i686-binutils 2.28-2
mingw-w64-i686-gcc 7.1.0-3
mingw-w64-i686-gcc-ada 7.1.0-3
mingw-w64-i686-gcc-fortran 7.1.0-3
mingw-w64-i686-gcc-libgfortran 7.1.0-3
mingw-w64-i686-gcc-libs 7.1.0-3
mingw-w64-i686-gcc-objc 7.1.0-3
mingw-w64-x86_64-binutils 2.28-2
mingw-w64-x86_64-gcc 7.1.0-3
mingw-w64-x86_64-gcc-ada 7.1.0-3
mingw-w64-x86_64-gcc-fortran 7.1.0-3
mingw-w64-x86_64-gcc-libgfortran 7.1.0-3
mingw-w64-x86_64-gcc-libs 7.1.0-3
mingw-w64-x86_64-gcc-objc 7.1.0-3

[Wayne Stambaugh (stambaughw)]

So that does not appear to be the issue. What about the library dependencies? Do you have them pinned as well so there is no mixing of libraries built with newer versions of gcc and binutils?

[Nick Østergaard (nickoe)]

@Wayne, I will list the packages inline below. Do you see any issues?

asciidoc 8.6.9-4
autoconf 2.69-3
autoconf2.13 2.13-2
autogen 5.18.12-1
automake-wrapper 10-1
automake1.10 1.10.3-3
automake1.11 1.11.6-3
automake1.12 1.12.6-3
automake1.13 1.13.4-4
automake1.14 1.14.1-3
automake1.15 1.15-2
automake1.6 1.6.3-2
automake1.7 1.7.9-2
automake1.8 1.8.5-3
automake1.9 1.9.6-2
bash 4.4.012-1
bash-completion 2.5-1
bison 3.0.4-1
bsdcpio 3.3.1-1
bsdtar 3.3.1-1
bzip2 1.0.6-2
catgets 1.1-2
coreutils 8.26-1
crypt 1.4-1
curl 7.54.0-1
dash 0.5.9.1-1
diffstat 1.61-1
diffutils 3.5-1
dos2unix 7.3.5-1
file 5.30-1
filesystem 2017.05-1
findutils 4.6.0-1
flex 2.6.4-1
gawk 4.1.4-2
gcc-libs 6.3.0-1
gdb 7.11.1-1
gettext-devel 0.19.8.1-1
git 2.13.3-1
gnu-netcat 0.7.1-1
gperf 3.1-1
grep 3.0-1
groff 1.22.3-1
gzip 1.8-1
help2man 1.47.3-1
inetutils 1.9.4-1
info 6.3-1
intltool 0.51.0-2
lemon 3.8.7.0-1
less 481-1
libtool 2.4.6-2
libunrar 5.5.3-1
lndir 1.0.3-1
make 4.2.1-1
man-db 2.7.6-1
mingw-w64-i686-binutils 2.28-2
mingw-w64-i686-boost 1.60.0-5
mingw-w64-i686-cairo 1.15.6-1
mingw-w64-i686-cmake 3.9.1-1
mingw-w64-i686-crt-git 5.0.0.4889.81b4f0e2-1
mingw-w64-i686-curl 7.54.1-1
mingw-w64-i686-doxygen 1.8.13-4
mingw-w64-i686-gcc 7.1.0-3
mingw-w64-i686-gcc-ada 7.1.0-3
mingw-w64-i686-gcc-fortran 7.1.0-3
mingw-w64-i686-gcc-libgfortran 7.1.0-3
mingw-w64-i686-gcc-libs 7.1.0-3
mingw-w64-i686-gcc-objc 7.1.0-3
mingw-w64-i686-gdb 8.0-2
mingw-w64-i686-glew 2.0.0-1
mingw-w64-i686-glm 0.9.8.3-1
mingw-w64-i686-headers-git 5.0.0.4891.8629b425-1
mingw-w64-i686-libmangle-git 5.0.0.4760.d3089b5-1
mingw-w64-i686-libwinpthread-git 5.0.0.4850.d1662dc7-1
mingw-w64-i686-make 4.2.1-1
mingw-w64-i686-ngspice 27-1
mingw-w64-i686-oce 0.17.2-4
mingw-w64-i686-pkg-config 0.29.2-1
mingw-w64-i686-python2 2.7.14-5
mingw-w64-i686-python2-pip 9.0.1-3
mingw-w64-i686-python3 3.6.2-2
mingw-w64-i686-swig 3.0.12-1
mingw-w64-i686-tools-git 5.0.0.4849.1259532f-1
mingw-w64-i686-winpthreads-git 5.0.0.4850.d1662dc7-1
mingw-w64-i686-winstorecompat-git 5.0.0.4760.d3089b5-1
mingw-w64-i686-wxPython 3.0.2.0-6
mingw-w64-i686-wxWidgets 3.0.3-1
mingw-w64-x86_64-binutils 2.28-2
mingw-w64-x86_64-boost 1.60.0-5
mingw-w64-x86_64-cairo 1.15.6-1
mingw-w64-x86_64-cmake 3.9.1-1
mingw-w64-x86_64-crt-git 5.0.0.4889.81b4f0e2-1
mingw-w64-x86_64-curl 7.54.1-1
mingw-w64-x86_64-doxygen 1.8.13-4
mingw-w64-x86_64-gcc 7.1.0-3
mingw-w64-x86_64-gcc-ada 7.1.0-3
mingw-w64-x86_64-gcc-fortran 7.1.0-3
mingw-w64-x86_64-gcc-libgfortran 7.1.0-3
mingw-w64-x86_64-gcc-libs 7.1.0-3
mingw-w64-x86_64-gcc-objc 7.1.0-3
mingw-w64-x86_64-gdb 8.0-2
mingw-w64-x86_64-glew 2.0.0-1
mingw-w64-x86_64-glm 0.9.8.3-1
mingw-w64-x86_64-headers-git 5.0.0.4891.8629b425-1
mingw-w64-x86_64-libmangle-git 5.0.0.4760.d3089b5-1
mingw-w64-x86_64-libwinpthread-git 5.0.0.4850.d1662dc7-1
mingw-w64-x86_64-make 4.2.1-1
mingw-w64-x86_64-ngspice 27-1
mingw-w64-x86_64-oce 0.17.2-4
mingw-w64-x86_64-pkg-config 0.29.2-1
mingw-w64-x86_64-python2 2.7.14-5
mingw-w64-x86_64-python2-pip 9.0.1-3
mingw-w64-x86_64-python3 3.6.2-2
mingw-w64-x86_64-swig 3.0.12-1
mingw-w64-x86_64-tools-git 5.0.0.4849.1259532f-1
mingw-w64-x86_64-winpthreads-git 5.0.0.4850.d1662dc7-1
mingw-w64-x86_64-winstorecompat-git 5.0.0...

[Wayne Stambaugh (stambaughw)]

@Nick, I don't see anything in your list that stands out other than you are using much older dependency libraries than I am. I'm using the latest dependency libraries and build tools available from the msys2 project so that could be the difference. I'm guessing you would not be able to use the latest dependency libraries with the older build tools due to abi incompatibilities. How much trouble would it be to create a new build using the latest msys2 packages? This is what I am using for my builds so this may be the difference. Did you ever build HEAD of the 5.0 branch with your current msys2 configuations after Seth reverted his change that broke the Eagle plugin? If so, where can I find these packages so I can test them?

[Nick Østergaard (nickoe)]

The 5.0 branch it built and uploaded to http://downloads.kicad-pcb.org/windows/testing/5.0/

Currently it only builds for 64-bit, but I can enable 32-bit builds as well.

I did test the first fix he made for it, which means that it works for the 5.0 branch for 64-bit at least.

[Nick Østergaard (nickoe)]

Please test with latest build from the build mentioned in #30.

[Seth Hillbrand (sethh)]

@Wayne- Does this still crash for you?

[Wayne Stambaugh (stambaughw)]

The current 5.0.1-3 installer build still crashes. My local builds (32 and 64 bit) of the head of the 5.0 branch work as expected. I know that the windows package builder was recently changed but I'm not sure that it is using the same build tool and dependency library versions that I am so there still could be issues with the 5.0.2 release windows installers.

[Seth Hillbrand (sethh)]

Can you test the 5.0.2 builds at http://downloads.kicad-pcb.org/windows/testing/5.0/

If they are good, I think we can close this report.

[Wayne Stambaugh (stambaughw)]

@Seth, that resolved the issue for me. I'm setting the status to fix committed. If someone is still having this issue, please set the status back to triaged.

[Nick Østergaard (nickoe)]

I also re-built 5.0.1 with the new toolchain in

http://downloads.kicad-pcb.org/windows/stable/kicad-5.0.1_4-x86_64.exe

Feel free to test.

[Bob (b-ansay)]

5.0.2 works for me, but 5.0.1 doesn't

[Nick Østergaard (nickoe)]

@bob, 5.0.1-<what-package-version?>

[Bob (b-ansay)]

I used the link you posted in #36

[Nick Østergaard (nickoe)]

Good, thank your for the datapoint. Everything is as expected now.