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.