pcbnew segfaults upon exit w/ Linux and wxWindows 3.0.3

[firewalker]

pcbnew will segfault upon exit with:

GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument. Aborting.
Aborted (core dumped)

It happens when pcbnew is called within kicad or as a standalone application.

Application: kicad
Version: (2017-06-24 revision 0719b99ad)-master, release build
Libraries: wxWidgets 3.0.3
           libcurl/7.54.1 OpenSSL/1.1.0f zlib/1.2.11 libpsl/0.17.0 (+libicu/59.1) libssh2/1.8.0 nghttp2/1.23.1
Platform: Linux 4.11.5-1-ARCH i686, 32 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.64.0
Curl: 7.54.1
KiCad - Compiler: GCC 7.1.1 with C++ ABI 1011
        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=OFF
                  BUILD_GITHUB_PLUGIN=ON
                  KICAD_USE_OCE=ON

Backtrace:

#0 0xb7fd9ce9 in __kernel_vsyscall ()
#1 0xb66e9392 in raise () at /usr/lib/libc.so.6
#2 0xb66eab73 in abort () at /usr/lib/libc.so.6
#3 0xb5e46b9a in () at /usr/lib/libglib-2.0.so.0
#4 0xb5e471cc in g_private_set () at /usr/lib/libglib-2.0.so.0
#5 0xb5e1e490 in g_slice_free1 () at /usr/lib/libglib-2.0.so.0
#6 0xb5ef268f in pango_font_description_free () at /usr/lib/libpango-1.0.so.0
#7 0xb7851a52 in wxNativeFontInfo::Free() () at /usr/lib/libwx_gtk2u_core-3.0.so.0
#8 0xb7882165 in () at /usr/lib/libwx_gtk2u_core-3.0.so.0
#9 0xb752c114 in wxObject::UnRef() () at /usr/lib/libwx_baseu-3.0.so.0
#10 0xb79ac324 in wxFontBase::~wxFontBase() () at /usr/lib/libwx_gtk2u_core-3.0.so.0
#11 0xb78821d4 in wxFont::~wxFont() () at /usr/lib/libwx_gtk2u_core-3.0.so.0
#12 0xb66ec47c in __cxa_finalize () at /usr/lib/libc.so.6
#13 0xb78398a3 in () at /usr/lib/libwx_gtk2u_core-3.0.so.0
#14 0xb7feaf7a in _dl_fini () at /lib/ld-linux.so.2
#15 0xb66ec113 in __run_exit_handlers () at /usr/lib/libc.so.6
#16 0xb66ec171 in () at /usr/lib/libc.so.6
#17 0xb66d525f in __libc_start_main () at /usr/lib/libc.so.6
#18 0x0805e124 in _start ()

[Nick Østergaard (nickoe)]

I can confirm this on archlinux too.

[Nick Østergaard (nickoe)]

Hmm, maybe this is realted to the upgrade to wxwidgets 3.0.3. I get the same segfault with kicad 4.0.6.

[jean-pierre charras (jp-charras)]

Be careful when upgrading wxWidgets to 3.03.
Be sure wxPython is also upgraded accordingly, because it is paired with wxWidgets.

[Nick Østergaard (nickoe)]

I don't see a new release of wxpython, except for 4.0

[jean-pierre charras (jp-charras)]

I am guessing wxPython just needs to be rebuilt against wxWidgets 3.03.
wxWidgets 3.03 is a bug fix release, therefore rebuilding wxPython should work and does not need a new wxPython sources version.

I can say using wxPython build against wxWidgets 3.02 and the new wxWidgets 3.03 binaries does not work on W7 (Pcbnew is unable to start the python console for instance).
On mingw32, wxPython was not rebuilt (not updated) against wxWidgets 3.03, and I am unable to use wxWidgets 3.03 to build Kicad with wxPython support (for that build, I am using wxWidgets 3.02).

wxPython and wxWidgets libraries are closely paired (in doc they must be built with the same compiler version for instance)

[Nick Østergaard (nickoe)]

Well yes, i have already done that such that there should not be any ABI mismatch.

[Nick Østergaard (nickoe)]

But it still segfaults on exit.

[firewalker (firew4lker)]

Yes, I tried recompiling wxpython with no results. It still segfaults.

[Maciej Suminski (orsonmmz)]

I think the root cause of the problem is that there is no wxPython 3.0.3 release and I doubt there will ever be. I have just upgraded wxgtk (Arch Linux) to 3.0.3 and the scripting builds stopped working.

[Wayne Stambaugh (stambaughw)]

On msys2 I had to downgrade to 3.0.2 to even get it to build. It looks
like we might be stuck with 3.0.2 for a while unless we build with
wxPython disabled. I agree that the motivation for wx to provide a
wxPython 3.0.3 is low now that they are working on Phoenix.

On 6/26/2017 8:31 AM, Maciej Sumiński wrote:
> I think the root cause of the problem is that there is no wxPython 3.0.3
> release and I doubt there will ever be. I have just upgraded wxgtk (Arch
> Linux) to 3.0.3 and the scripting builds stopped working.
>

[Nick Østergaard (nickoe)]

Did anyone try the phønix release of wxpython with kicad?

[Maciej Suminski (orsonmmz)]

I tried to switch to wxPhoenix, but it might be not a light change. If someone wants to takeover, I can share my branch.

[Nick Østergaard (nickoe)]

Please push your branch somewhere. I would like to test it.

[Maciej Suminski (orsonmmz)]

@Nick
There is nothing to test, the branch does not compile due to wxPython vs wxPhoenix interface changes. All I did is I convinced CMake to accept wxPhoenix instead wxPython (in an ugly way).

https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/wxphoenix

[Jeff Young (jeyjey)]

@Devs, are we likely to do anything with this, or should we close it?

[Nick Østergaard (nickoe)]

I guess this will be fixed by moving to wxphoenix, but this does not work as it right now. I guess mostly because it uses SIP instead of SWIG. I know this does not answer your question about getting a fix for this or not, but I think it is worth migrating to phoenix. It would be nice if it could happen for v5, but since it does not work yet, and I think only people have tested phoenix on linux I don't see it likely to be ready for v5.

[jean-pierre charras (jp-charras)]

On Windows/msys2, wxPython was rebuilt, and works fine since a long time.

[Wayne Stambaugh (stambaughw)]

@Jeff, I'm not sure there is much we can do about it. Arch linux users are either going to have to live without wxpython or use wxwidgets 3.0.2 if I'm following this correctly. This definitely seems like an issue from their end since wxwidgets 3.0.3 works on other platforms including debian testing.

@Nick, I don't see how we could use wxphoenix in v5 this late in the development cycle. It would be way too risky. AFAIK, wxphoenix hasn't even been packaged by most distros yet and that is the minimum criteria for introducing a new dependency into kicad. I wish we had a better solution but at the moment it is what it is.

[Nick Østergaard (nickoe)]

I guess since we can't do anything, then I am fine with closing it for now.

[Jeff Young (jeyjey)]

Cool; thanks everyone for the input.