kicad @7.0.11: crashes when run

[Gamespeople]

Catalina 10.15.7

Installed fine:

--->  Verifying checksums for kicad
--->  Extracting kicad
--->  Applying patches to kicad
--->  Configuring kicad
--->  Building kicad
--->  Staging kicad into destroot
--->  Installing kicad @7.0.11_0
--->  Activating kicad @7.0.11_0
--->  Cleaning kicad
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.

however when trying to launch KiCad 7.0.11 it crashes when I try to do anything past the opening screen.

Is this a Ports problem or a KiCad issue.

I've attached the Apple error report.
Thanks!

[Gamespeople]

Apple report on crash

[Gamespeople]

Normal open for new file - can't open any function without crashing...

[ryandesign (Ryan Carsten Schmidt)]

Hmm. The crash log says:

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   org.kicad.kicad               	0x0000000101fe548b KIWAY::Player(FRAME_T, bool, wxTopLevelWindow*) + 219
1   org.kicad.kicad               	0x0000000101e8b5cc KICAD_MANAGER_CONTROL::ShowPlayer(TOOL_EVENT const&) + 428
2   org.kicad.kicad               	0x000000010207d3e1 COROUTINE<int, TOOL_EVENT const&>::callerStub(long) + 49

I'm not sure why. I clicked around in the interface a bit and could not make it crash on macOS 12.

The mention of wx in the backtrace reminds me that we already know that we are not conforming to kicad's requirements by using it with a standard copy of wxWidgets. kicad wants us to use their fork of wxWidgets instead. I had kinda expected to need to switch to that for the update to kicad 8 anyway. It seems like a lot of work to need to build it separately so I was going to investigate if there is a preferred way to build kicad and their fork of wxWidgets and any other custom dependencies all at once in the kicad port.

[Gamespeople]

Well, the point of using macports was to enable kicad 7.0.11 to be able to run in macOS 10.15.x, as kicad does run in macOS 12 natively. Appreciate your looking into this! Thanks!

[Gamespeople]

Anything I can do to help resolve this issue?

I just ran an update on MacPorts as well as checking for "sudo port upgrade outdated", "sudo port clean --dist kicad", and "sudo port install kicad" with no change - just in case MacPorts had been fixed for this problem.

Any luck with the wxWidgets?

It is frustrating to have to run KiCAD in VmWare Fusion instead of directly on my Catalina machine.

Thanks for your time! Those of us running older mac hardware (MacBook Pro 2012) appreciate it!

[ryandesign (Ryan Carsten Schmidt)]

Replying to Gamespeople:

Any luck with the wxWidgets?

I haven't worked on it.

Replying to ryandesign:

I was going to investigate if there is a preferred way to build kicad and their fork of wxWidgets and any other custom dependencies all at once in the kicad port.

The ​preferred build process is not usable by MacPorts since it relies upon—and even automatically installs—our competitor Homebrew.

[Gamespeople]

I was searching for other folks working on this issue and found the following (link):

​https://wentingzhang.com/post/kicad_7_mac_os_x_10_15/

Mr. Zhang appears to have found a workaround for MacPorts, which, unfortunately, is above my regular skill set. I can figure it out over time, but perhaps it makes sense to you - and you can do the magic coding to sort it out for us dullards.

Where I am having trouble is with the line:

diff --git a/build.py b/build.py

as it appears that this is a MacPorts 'diff' command instruction '--git' as the default OSX diff hasn't a clue about '--git'. Can't find anything but diffutils on MacPorts so far... Thanks!

[ryandesign (Ryan Carsten Schmidt)]

Replying to Gamespeople:

I was searching for other folks working on this issue and found the following (link):

​https://wentingzhang.com/post/kicad_7_mac_os_x_10_15/

Thanks, I'll take a look.

Where I am having trouble is with the line:

diff --git a/build.py b/build.py

This is not a command you are intended to run; it is the first line of output git diff displays when it shows you a diff. You apply a diff using the patch command.

[Gamespeople]

Drat, I don't know that patch command process at all... I'll ask a friend if he can help me when he has time. I'll report back here with what I did if successful.

Thanks!

[ryandesign (Ryan Carsten Schmidt)]

To try the build, you would presumably check out the kicad-mac-builder repository (git clone https://gitlab.com/kicad/packaging/kicad-mac-builder.git), change into its directory (cd kicad-mac-builder), and before you follow the instruction to run ./build.py, you would apply the two patches in that blog post. To do that, go to the blog post and copy all the text starting at diff --git a/build.py b/build.py and ending at (END) and paste it into a text file called patch1 that you save in the kicad-mac-builder directory and copy all of the text starting at diff --git a/cmake/FindOCC.cmake b/cmake/FindOCC.cmake and ending at (END) and paste it into a text file called patch2 that you save in the kicad-mac-builder directory. To apply both patches, run patch -p1 < patch1 and patch -p1 < patch2.

[ryandesign (Ryan Carsten Schmidt)]

Uh, I guess I didn't read the blog post closely enough. patch1 is for the kicad-mac-builder repository. patch2 is for the kicad repository.

[Gamespeople]

So I assume I run patch1 in the kicad-mac-builder directory, but where do I put patch2?

Is it as simple as using the same instruction for patch1 in the kicad repository after running (git clone ​https://gitlab.com/kicad/packaging/kicad.git) or is that assumption incorrect?

Thanks!

[ryandesign (Ryan Carsten Schmidt)]

I assume so except that the URL is actually ​https://gitlab.com/kicad/code/kicad.git

[Gamespeople]

Patches for kicad-mac-builder and kicad builds

[Gamespeople]

So, now I have patched the two builds, how do I run them from here (my Macbook Pro)?

Thanks again!

[ryandesign (Ryan Carsten Schmidt)]

Well I don't know. You'll have to find and follow the instructions, such as ​https://dev-docs.kicad.org/en/build/macos/

[cdavis5e (Chip Davis)]

Patch to fix broken RTTI references in KiCad

[cdavis5e (Chip Davis)]

I've looked at this, and I think I know what the problem is.

The crash log obscures the actual problem. The actual problem occurs when KiCad is loading the plugin or "KiFace" for the tool that was selected. As part of this process, the KiFace attempts to grab the settings object for KiCad itself of type KICAD_SETTINGS. But the SETTINGS_MANAGER object stores the settings it knows about as pointers to the base class, JSON_SETTINGS. In order to return a settings object by type, it must dynamic_cast each of the pointers until it finds the one the caller is looking for. This is where the problem happens.

In order to perform a dynamic_cast, type information is required. The Itanium C++ ABI that Darwin uses requires type info data to be unique--except, apparently, on Apple Silicon, where Windows-style duplicates are tolerated. Because of KiCad's linking model, two copies of the type info are present, one in the kicad binary itself and the other in the KiFace binary. The KICAD_SETTINGS object was created by kicad, but is being accessed by the KiFace. But because the type info pointers don't match, the dynamic_cast on the correct object fails, so the SETTINGS_MANAGER is unable to find the object the KiFace is looking for, and thus the KiFace throws an exception, which causes KiCad to fail loading the KiFace binary and, because it tries to use a null pointer, it crashes.

It isn't limited to this particular instance. dynamic_casts abound in KiCad's source code. All of these are potential land mines waiting to go off. The right solution IMO is to make the KiFaces import symbols from the main binary instead of linking in a separate copy of the type info. This should be possible since the KiFaces are binaries of type MH_BUNDLE, which is specifically allowed to import from a main binary, though I'm not sure how that would work when embedding with Python. A more pragmatic solution for our purposes might be to make the type info symbols weak; then, at run time, dyld(1) will coalesce them so that there is only one instance that is ever referenced. I'll attach a patch that implements this latter solution.

Based on what I said above, I'm guessing that this problem wouldn't show up on an Apple Silicon device--that's probably why the KiCad devs never caught it.

[ryandesign (Ryan Carsten Schmidt)]

This doesn't sound like a MacPorts-specific problem but rather a design flaw in KiCad, so I hope you'll take your findings to the developers of KiCad and work with them on the correct solution.

[ryandesign (Ryan Carsten Schmidt)]

Chip, see my comment above.

[Gamespeople]

Chip - except I'm trying to run this on a 2012 Macbook Pro - Catalina 10.15.7 - running on an Intel 2.3GHz Quad-Core cpu w/16GB DDR3 RAM.

Apple Silicon doesn't happen for a few more years - 2020 - and later versions of KiCad seem to run quite happily on Apple Silicon...

[cdavis5e (Chip Davis)]

Replying to Gamespeople:

Chip - except I'm trying to run this on a 2012 Macbook Pro - Catalina 10.15.7 - running on an Intel 2.3GHz Quad-Core cpu w/16GB DDR3 RAM.

Well, yeah. I debugged this problem on a 2016 Intel MacBook Pro on Mojave 10.14.6. That's why I said it probably wouldn't show up on an Apple Silicon device. It will show up on an Intel Mac on Catalina or lower.

I also suspect that this wouldn't show up on macOS 11+, Intel or Apple Silicon. I think Apple changed libcxxabi in that release to tolerate multiple definitions of type info data, by defining the preprocessor symbol _LIBCXXABI_FORGIVING_DYNAMIC_CAST when building libcxxabi. And in fact, when I try KiCad on an Intel Mac running Sonoma without the patch, it works just fine. For this reason, I suspect that help from upstream would be less than forthcoming, since KiCad 7 officially doesn't support any version of macOS prior to 11. But, one will never know unless one actually asks. The fact that exceptions would still be broken on Intel even with _LIBCXXABI_FORGIVING_DYNAMIC_CAST is probably a point in favor of asking.

[liqili (Kunkka)]

I got the same problem in my mac book Pro2015 on Catalina. The KiCad is on version 7.0.11. On my other iMac, the version 7.0.9 is running fine. So could you guys also enable the installation of 7.0.9 so that I can downgrade to that?

Application Specific Information: abort() called terminating with uncaught exception of type std::runtime_error

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff69a5a32a pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff69b16e60 pthread_kill + 430 2 libsystem_c.dylib 0x00007fff699e1808 abort + 120 3 libc++abi.dylib 0x00007fff66c3e458 abort_message + 231 4 libc++abi.dylib 0x00007fff66c2f8bf demangling_terminate_handler() + 262 5 libobjc.A.dylib 0x00007fff6876c5b1 _objc_terminate() + 104 6 libc++abi.dylib 0x00007fff66c3d887 std::terminate(void (*)()) + 8 7 libc++abi.dylib 0x00007fff66c3d829 std::terminate() + 41 8 libwx_baseu-3.2.dylib 0x00000001079db149 wxAppConsoleBase::RethrowStoredException() + 121 9 libwx_baseu-3.2.dylib 0x0000000107a0de2d wxEventLoopBase::YieldFor(long) + 109 10 libwx_osx_cocoau_core-3.2.dylib 0x00000001073e20c6 wxGenericProgressDialog::Update(int, wxString const&, bool*) + 54 11 _pcbnew.kiface 0x00000001109a1ded WX_PROGRESS_REPORTER::updateUI() + 237 12 _pcbnew.kiface 0x00000001109771f3 PROGRESS_REPORTER_BASE::KeepRefreshing(bool) + 83 13 _pcbnew.kiface 0x000000011071d7e3 PCB_PLUGIN::Load(wxString const&, BOARD*, STRING_UTF8_MAP const*, PROJECT*, PROGRESS_REPORTER*) + 563 14 _pcbnew.kiface 0x000000011000eab6 PCB_EDIT_FRAME::OpenProjectFiles(std::1::vector<wxString, std::1::allocator<wxString> > const&, int) + 5302 15 org.kicad.kicad 0x00000001066cdd68 KICAD_MANAGER_CONTROL::ShowPlayer(TOOL_EVENT const&) + 2376 16 org.kicad.kicad 0x00000001068bf3e1 COROUTINE<int, TOOL_EVENT const&>::callerStub(long) + 49

Thread 1: 0 libsystem_pthread.dylib 0x00007fff69b12b68 start_wqthread + 0

Thread 2:: com.apple.NSEventThread 0 libsystem_kernel.dylib 0x00007fff69a53dea mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff69a54160 mach_msg + 60 2 com.apple.CoreFoundation 0x00007fff2fc8e135 CFRunLoopServiceMachPort + 247 3 com.apple.CoreFoundation 0x00007fff2fc8cc02 CFRunLoopRun + 1319 4 com.apple.CoreFoundation 0x00007fff2fc8c07e CFRunLoopRunSpecific + 462 5 com.apple.AppKit 0x00007fff2d0a2bf4 _NSEventThread + 132 6 libsystem_pthread.dylib 0x00007fff69b17109 _pthread_start + 148 7 libsystem_pthread.dylib 0x00007fff69b12b8b thread_start + 15

Thread 3:: com.apple.CFSocket.private 0 libsystem_kernel.dylib 0x00007fff69a5c0ee select + 10 1 com.apple.CoreFoundation 0x00007fff2fcb6e93 CFSocketManager + 641 2 libsystem_pthread.dylib 0x00007fff69b17109 _pthread_start + 148 3 libsystem_pthread.dylib 0x00007fff69b12b8b thread_start + 15

Thread 4: 0 libsystem_pthread.dylib 0x00007fff69b12b68 start_wqthread + 0

Thread 5: 0 libsystem_pthread.dylib 0x00007fff69b12b68 start_wqthread + 0

Thread 6: 0 libsystem_kernel.dylib 0x00007fff69a56872 psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff69b17425 _pthread_cond_wait + 698 2 libc++.1.0.dylib 0x0000000108686af2 std::1::condition_variable::wait(std::1::unique_lock<std::__1::mutex>&) + 18 3 _pcbnew.kiface 0x0000000110f0622d BS::thread_pool::worker() + 189 4 _pcbnew.kiface 0x0000000110f065ce void* std::1::thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (BS::thread_pool::*)(), BS::thread_pool*> >(void*) + 62 5 libsystem_pthread.dylib 0x00007fff69b17109 _pthread_start + 148 6 libsystem_pthread.dylib 0x00007fff69b12b8b thread_start + 15

Thread 7: 0 libsystem_kernel.dylib 0x00007fff69a56872 psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff69b17425 _pthread_cond_wait + 698 2 libc++.1.0.dylib 0x0000000108686af2 std::1::condition_variable::wait(std::1::unique_lock<std::__1::mutex>&) + 18 3 _pcbnew.kiface 0x0000000110f0622d BS::thread_pool::worker() + 189 4 _pcbnew.kiface 0x0000000110f065ce void* std::1::thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (BS::thread_pool::*)(), BS::thread_pool*> >(void*) + 62 5 libsystem_pthread.dylib 0x00007fff69b17109 _pthread_start + 148 6 libsystem_pthread.dylib 0x00007fff69b12b8b thread_start + 15

Thread 8: 0 libsystem_kernel.dylib 0x00007fff69a56872 psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff69b17425 _pthread_cond_wait + 698 2 libc++.1.0.dylib 0x0000000108686af2 std::1::condition_variable::wait(std::1::unique_lock<std::__1::mutex>&) + 18 3 _pcbnew.kiface 0x0000000110f0622d BS::thread_pool::worker() + 189 4 _pcbnew.kiface 0x0000000110f065ce void* std::1::thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (BS::thread_pool::*)(), BS::thread_pool*> >(void*) + 62 5 libsystem_pthread.dylib 0x00007fff69b17109 _pthread_start + 148 6 libsystem_pthread.dylib 0x00007fff69b12b8b thread_start + 15

Thread 9: 0 libsystem_kernel.dylib 0x00007fff69a56872 psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff69b17425 _pthread_cond_wait + 698 2 libc++.1.0.dylib 0x0000000108686af2 std::1::condition_variable::wait(std::1::unique_lock<std::__1::mutex>&) + 18 3 _pcbnew.kiface 0x0000000110f0622d BS::thread_pool::worker() + 189 4 _pcbnew.kiface 0x0000000110f065ce void* std::1::thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (BS::thread_pool::*)(), BS::thread_pool*> >(void*) + 62 5 libsystem_pthread.dylib 0x00007fff69b17109 _pthread_start + 148 6 libsystem_pthread.dylib 0x00007fff69b12b8b thread_start + 15

Thread 10: 0 libsystem_pthread.dylib 0x00007fff69b12b68 start_wqthread + 0

Thread 0 crashed with X86 Thread State (64-bit):

rax: 0x0000000000000000 rbx: 0x0000000108ab7dc0 rcx: 0x00007f815a0825f8 rdx: 0x0000000000000000 rdi: 0x0000000000000307 rsi: 0x0000000000000006 rbp: 0x00007f815a082620 rsp: 0x00007f815a0825f8

r8: 0x00007f815a0824c0 r9: 0x00007f815a082690 r10: 0x0000000108ab7dc0 r11: 0x0000000000000246

r12: 0x0000000000000307 r13: 0x0000003000000008 r14: 0x0000000000000006 r15: 0x0000000000000016 rip: 0x00007fff69a5a32a rfl: 0x0000000000000246 cr2: 0x00007fff66c3baee

Logical CPU: 0 Error Code: 0x02000148 Trap Number: 133

Binary Images:

0x106680000 - 0x106d8ff53 +org.kicad.kicad (7.0.11 - 7.0.11) <532BEBD4-3A0F-3E81-8E08-43368D487F53> /Applications/MacPorts/*/kicad.app/Contents/MacOS/kicad 0x106fe5000 - 0x106fe6fff +libMacportsLegacySupport.dylib (0) <FA6B4C80-4A21-360F-93D2-A182FF2CDB05> /opt/local/lib/libMacportsLegacySupport.dylib 0x106fea000 - 0x106feafff +libX11-xcb.1.dylib (0) <3C5FCD8F-C3B1-3007-BF49-5DAFE1095572> /opt/local/lib/libX11-xcb.1.dylib 0x106fef000 - 0x106ffaff3 +libwx_osx_cocoau_gl-3.2.dylib (0) <57384388-8FAA-358E-B2A7-CEA23DBC6D6F> /opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/libwx_osx_cocoau_gl-3.2.dylib 0x10700d000 - 0x10706bff7 +libwx_osx_cocoau_aui-3.2.dylib (0) <E4709434-5554-320F-8D37-F46FED74712C> /opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/libwx_osx_cocoau_aui-3.2.dylib 0x1070ae000 - 0x10711effb +libwx_osx_cocoau_html-3.2.dylib (0) <DBD6F922-5A47-34B7-9984-AA755263C471> /opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/libwx_osx_cocoau_html-3.2.dylib

[ryandesign (Ryan Carsten Schmidt)]

Remember to use WikiFormatting so things are legible.

Replying to liqili:

So could you guys also enable the installation of 7.0.9 so that I can downgrade to that?

I don't think we would spend any time downgrading the port to 7.0.9; we should work on upgrading the port to a working version of 8.x instead. See wiki:howto/InstallingOlderPort if you want to install an older version of any port, with the caveat that it is not supported.