KiCad hangs on exit if the scripting console was open (GTK3+Python3)

[Fabián Inostroza]

Open the scripting console and then close KiCad, the process keeps running in the background.

This doesn't happen when using a build that uses GTK2 and Python 2.7.

Application: kicad
Version: (6.0.0-rc1-dev-1437-g4d9b4428f-dirty), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.62.0 GnuTLS/3.5.19 zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.35.1 librtmp/2.3
Platform: Linux 4.18.0-3-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.67.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.62.0
    Compiler: GCC 8.2.0 with C++ ABI 1013

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

[Seth Hillbrand (sethh)]

Since we are expecting python3 to be used in many distributions, we will need to resolve this for 5.1

[Thomas Pointhuber (pointhi)]

The Event Loop is still running:

```
Thread 1 "pcbnew" received signal SIGINT, Interrupt.
0x00007ffff60d8c21 in poll () from /usr/lib/libc.so.6
(gdb) backtrace
#0 0x00007ffff60d8c21 in poll () at /usr/lib/libc.so.6
#1 0x00007ffff54e7540 in () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff54e85c2 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff5add2bf in gtk_main () at /usr/lib/libgtk-3.so.0
#4 0x00007ffff7841c46 in wxGUIEventLoop::DoRun() () at /usr/lib/libwx_gtk3u_core-3.0.so.0
#5 0x00007ffff738ebae in wxEventLoopBase::Run() () at /usr/lib/libwx_baseu-3.0.so.0
#6 0x00007ffff7353517 in wxAppConsoleBase::MainLoop() () at /usr/lib/libwx_baseu-3.0.so.0
#7 0x000055555558af05 in APP_SINGLE_TOP::OnRun() (this=0x5555556b5470) at ./kicad-source/common/single_top.cpp:186
#8 0x00007ffff73db4c8 in wxEntry(int&, wchar_t**) () at /usr/lib/libwx_baseu-3.0.so.0
#9 0x0000555555585f30 in main(int, char**) (argc=1, argv=0x7fffffffda18) at ./kicad-source/common/single_top.cpp:260
```

I suspect the creation of an additional wx.App() could be the reason for the problem. I created an issue on wxPhoenix to clarify how to correctly instantiate a wxPython frame based on a c++ parent https://github.com/wxWidgets/Phoenix/issues/1126

[Thomas Pointhuber (pointhi)]

I don't think I can look into the issue until FOSDEM.

A possible fix which could work would be reverting some code changes, which were required because wxpy_api.h was not included in wxPhoenix in the past (https://github.com/wxWidgets/Phoenix/issues/961). But not guarantee that this fix the issue.

[Seth Hillbrand (sethh)]

It looks like maybe we could pass wxTheApp in explicitly when instantiating the shell and then call wx.AppConsole.SetInstance() in the python initialization.

[KiCad Janitor (kicad-janitor)]

Fixed in revision 8b060799ebcde69dab29565ca5dd63d36c6ac87b
https://git.launchpad.net/kicad/patch/?id=8b060799ebcde69dab29565ca5dd63d36c6ac87b

[Seth Hillbrand (sethh)]

In the meantime, while we figure out the Phoenix mishegas, I've implemented a work-around that allows KiCad to keep working normally. Ideally, we'd like to get the PyShell and KiCad using the same wxApp and event handler but we can live with this for 5.1