Hello,
Around a month ago, the Fedora KiCad maintainer reported that kicad started crashing when we updated to Python 3.14:
I maintain the KiCad packages. We have a new bug report:
2393850 – kicad crashes during python runtime initialization
Here is the gist of it:
Fatal Python error: _Py_CheckRecursiveCall: Unrecoverable stack overflow (used -406047 kB) while calling a Python object
A couple of attempts to find the cause later, they reported this to KiCAD upstream (including attached backtraces etc.). One of the KiCAD users investigated:
When I looked at the stack pointer in the recursion check it looked completely different from the stack limit it was comparing to, which makes me think this is really a threading confusion - something like a stack limit read on one stack (interpreter creation???) and then checking against it on a completely different thread where the call is made??
And the KiCAD maintainers closed the issue (emphasis mine):
This is not really fixable by KiCad I think. Python 3.14 changed how they guard recursion and the limits are set outside of our control.
cpython/InternalDocs/stack_protection.md at main · python/cpython · GitHub
It used to be just a counter-based thing that we were able to stay inside of. Now, depending on the compile flags, we could hit the limit (obviously) very quickly.
I would suggest reviewing the Python settings in Fedora. Maybe changing compile flags to reduce your CPython frame size.
Any case, I’ll close this issue as not addressable here. You can still comment and we’ll still see it but it’s not really something we can close as fixed
Is this really something we (Fedora Python maintainers) should be looking into? Or is this a bug in Python? Why is the used stack size negative (smells like an int overflow)?¨
I would appreciate your help with this.