Right now, the Fedora 43 version of KiCad schematic editor does not work at all, and immediately aborts with errors like Fatal Python error: _Py_CheckRecursiveCall: Unrecoverable stack overflow (used -710155 kB) while calling a Python object Python runtime state: initialized but the bug is not in KiCad, it is in a completely broken stack range check in python-3.14. Reproducible: Always Steps to Reproduce: 1. Run kicad 2. Start the schematic editor (or pcb editor) 3. Profit! Wait - no. Abort Actual Results: Fatal Python error: _Py_CheckRecursiveCall: Unrecoverable stack overflow (used -710155 kB) while calling a Python object Python runtime state: initialized Current thread 0x00007fc3044cf000 [kicad] (most recent call first): <no Python frame> Aborted (core dumped) kicad Expected Results: Actually working kicad installation (and presumably other threaded applications too) Additional Information: This bug seems to have been introduced in cpython by commit 014223649c3 ("GH-130396: Use computed stack limits on linux (GH-130398)"). It appears to have been fixed in the development branch of cpython by commit c25a0707599 ("GH-139653: Only raise an exception (or fatal error) when the stack pointer is about to overflow the stack. (GH-141711)") but the fix is not in the 3.14 branch. Please disable the completely buggy check for now in the Fedora tree, until the python people get their act together in the 3.14 branch and actually have a working version.
Created attachment 2115606 [details] Disable buggy stack test entirely This is the minimal patch to just disable the buggy code. The real fix is something the python developers are apparently discussing, but in the meantime a serious python bug should not hold up other programs!
Hello Linus. As you mentioned, the problem is currently being discussed Python upstream: https://discuss.python.org/t/python-3-14-0-is-incompatible-with-stack-switching-systems-what-do-we-do/104880 I hope upstream will come up with a reasonable solution soon (I haven't yet read the recent comments in the discussion). Perhaps by disabling the thing entirely. As far as kicad goes, there is: - a Fedor tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2393850 - upstream kicad issue: https://gitlab.com/kicad/code/kicad/-/issues/21890 - Python issue: https://github.com/python/cpython/issues/139653
Instead of disabling this entirely, I hope the solution would be to backport the change from the main branch. We will get to this early next week.
(In reply to Miro Hrončok from comment #3) > Instead of disabling this entirely, I hope the solution would be to backport > the change from the main branch. We will get to this early next week. This is literally breaking applications that people use, for a debug feature that is COMPLETELY BROKEN and adds no value. So why wait? Why does that stupid check even exist? If somebody wants a stack limit, why aren't they using "ulimit -s"? You know, that thing that *works*, and has been around forever, instead of a known-broken "feature" that adds no actual value, and breaks real applications? Now, I haven't actually tested that there aren't other problems, but I really find it distasteful that this has apparently been broken for a long while, it was marked release blocking in the python issues, and this broken garbage was *still* left alone despite not actually having any valid reason for existing in the first place. So what is holding up removal of it? Why even bother "fixing" it?
Created attachment 2115733 [details] Disable stack tests more completely This one is actually tested with kicad, and makes things work. There were a few other places that checked the stack pointer using the wrong logic, that broke in threaded environments where there are multiple stacks
> This is literally breaking applications that people use, for a debug feature > that is COMPLETELY BROKEN and adds no value. I recognize your concerns. > So why wait? Nobody is waiting. I cannot get to this before early next week. It's Saturday, most of the Python maintainers in Fedora are not working, nor am I. This was released as Fedora 43 on October 28, it can wait a couple more days. I have the capacity to reply to your comments, but not to apply patches. > Why does that stupid check even exist? I don't know. As a Fedora Python maintainer, I do not know every reason for every change in Python. We work tirelessly, integrating a new Python version into Fedora for a year. Until now, this was not flagged as urgent, and suddenly it is. I am sorry this breaks your apps, but there's nothing I can do about that right now, this minute. We will likely get to it early next week. > If somebody wants a stack limit, why > aren't they using "ulimit -s"? You know, that thing that *works*, and has > been around forever, instead of a known-broken "feature" that adds no actual > value, and breaks real applications? Please, bring this to Python upstream. > Now, I haven't actually tested that there aren't other problems, but I > really find it distasteful that this has apparently been broken for a long > while, it was marked release blocking in the python issues, and this broken > garbage was *still* left alone despite not actually having any valid reason > for existing in the first place. Yes, this was broken for a long time. Yet now it needs to be fixed immediately :/ > So what is holding up removal of it? Life. > Why even bother "fixing" it? Generally, I believe fixing stuff is the better way to go than removing it. There are cases when immediate revert is a better solution. This might even be such a case, but we will deal with it early next week.
(In reply to Miro Hrončok from comment #6) > > Yes, this was broken for a long time. Yet now it needs to be fixed > immediately :/ It needed to be fixed almost two *months* ago, before the 3.14 release. Python people clearly knew about it. It's in their own issues database. But what has changed is that now it's released in Fedora 43, and now it affects people who installed that. So now it's a Fedora issue, and since the python people haven't fixed it, it's time to step up. I sent a patch. My patch may not be perfect, because honestly, this is the first time I've looked at python sources, but it's certainly better than what is there today. Yes, *I* can build my own local copy of cpython, and install it in a temporary location, and run kicad with LD_LIBRARY_PATH hacks etc. And it's what I have done. It kind of works. I say "it kind of works", because then you end up with a very limited python install, and you can't actually run any python scripts because you get a Could not determine wxWidgets version. Python plugins will not be available. because I only did that minimal thing to check that the crash is gone. It so happens that I don't actually use many KiCad plugins, so it's actually working well enough for me in this very limited and broken form. I'm not going to bother doing a full environment when the limited one is sufficient for my needs, and I really just wanted to verify that nothing *else* was broken too. But other Fedora users? Most people rely on not having broken packages, and aren't going to try to debug this and recompile their own version of cpython.
Oh, and there's something else wrong with KiCad in Fedora 43. I initially thought it was all due to my hacky cpython library limited install, and it still *might* be it. But while using kicad just to look at schematics and simulating the circuits was working fairly well, when I actually tried to *edit* things, it starts out normal, but at some point the mouse input starts acting all funky. I don't know what triggers it - it starts out nice and smooth and responsive, and then at some point some operations end up acting like they ignore mouse input entirely or have multi-second latencies or whatever. And then it's entirely unusable. Kicad is doing some unusual things, notably it uses wxWidgets. I think kicad and audacity are the two main users of that cross-platform library. I'd still love to have a usable (complete) python3.14 install because the non-working python hides all other problems. But there might be other things lurking here.
> Nobody is waiting. I cannot get to this before early next week. It's > Saturday, most of the Python maintainers in Fedora are not working, nor am > I. This was released as Fedora 43 on October 28, it can wait a couple more > days. I have the capacity to reply to your comments, but not to apply > patches. It certainly feels like waiting to me. This is a known issue, and yet there's still no fix after all this time. It's been almost two months and the problem persists. > Yes, this was broken for a long time. Yet now it needs to be fixed > immediately :/ Fine, then it can wait for the Fedora 44 release, I guess. Once the Fedora maintainers shipped this change, they took responsibility for fixing resulting issues as soon as possible. This doesn't only affect KiCad — it likely breaks other software applications that people rely on every day. If this really can wait, please at least document it clearly in the Fedora 43 release notes or change log so users are warned that some applications may stop working after the update. > Life. This is exactly why I'm replying. I found that response disrespectful. I completely understand you're on your own time and it's the weekend, but this is a long-standing known issue that forces users into bad situations — like downgrading to Fedora 42 (which can break their system), doing a fresh install and losing all their data, or just giving up on Fedora entirely. I'm sorry if I'm missing something or misunderstanding the situation, but this should have been addressed a while ago so users can just update and keep working without running into broken packages. Many users (including me) are waiting for a solution and are actively blocked from doing their work. Please prioritize fixing this issue as soon as possible.
We are actively looking into this, and we hope to have this fixed really soon. This will certainly not wait for the Fedora 44 release. But it was not violating any of the release criteria for Fedora 43. Considering the imminent fix, I don't think that documenting this in the Fedora 43 release notes at this point adds much value, but if you'd like to contribute to that, please do: https://docs.fedoraproject.org/en-US/fedora-docs/contributing-docs/tools-gitlab-howto/ I am sincerely sorry if this makes you give up on Fedora entirely. As Python maintainers in Fedora, we cannot hold up upgrading Python or releasing new Fedora for every single app that is broken. That's not realistically possible even if we had more people working on it. Despite that, we try really hard not to break anything. I encourage you to participate in early testing of Fedora pre-releases and report problems that block you sooner. We take user-reported problems very seriously, but we cannot take responsibility for fixing every issue right when it is reported. There are always multiple things to fix, multiple other priorities to handle, and yes, life. I don't consider that disrespectful -- I am not a robot, I have life beyond Fedora, and I think it's absolutely OK to recognize that. If this is blocking you from using KiCad, you may try installing it from flathub instead: https://flathub.org/en/apps/org.kicad.KiCad If this is blocking you from using other apps, please be specific.
For the record, the attached patch cannot be applied as-is because it causes a Segmentation fault during PGO tests. Nevertheless, here's a Fedora 43 scratchbuild with the patch applied and PGO + tests disabled: https://koji.fedoraproject.org/koji/taskinfo?taskID=139280282 if you wish to test it with kicad. However, I strongly advise against installing that on non-test systems.
> It's been almost two months and the problem persists. Well, it takes time to design a fix. Obviously, it was proposed to revert to Python 3.13 stack overflow detection code, but this idea was put aside. Python 3.14 has better code to detect stack overflow which fix many old issues about C stack overflow. I designed a new PyUnstable_ThreadState_SetStackProtection() API for KiCad: * https://github.com/python/cpython/issues/139653 * https://github.com/python/cpython/pull/139668 * https://github.com/capi-workgroup/decisions/issues/81 In the meanwhile, other projects reported that they are also affected by the issue, and may not be able to use PyUnstable_ThreadState_SetStackProtection() API. So yet another fix was written. We are now backporting these non-trivial changes to Python 3.14. There are multiple issues: * KiCad and other affected projects were only tested after Python 3.14.0 final release. The incompatibility was discovered late. * There is no simple (short) reproducer, it usually requires to install a whole project to trigger the bug. * Only few Python developers understand and can fix the stack overflow detection code. --- In the meanwhile, Miro offered workarounds (like using Flatpak).
Here's a build with a backport and all tests enabled: https://koji.fedoraproject.org/koji/taskinfo?taskID=139283586 I am going to test it with kicad.
Without the fix, I start kicad and start new project, I get: Fatal Python error: _Py_CheckRecursiveCall: Unrecoverable stack overflow (used -1098045 kB) while calling a Python object Python runtime state: initialized Current thread 0x00007fc8dbfa7240 [kicad] (most recent call first): <no Python frame> Aborted (core dumped) kicad With the build from Comment 13 installed via: sudo dnf install https://kojipkgs.fedoraproject.org//work/tasks/3605/139283605/python-unversioned-command-3.14.0-100.fc43.noarch.rpm https://kojipkgs.fedoraproject.org//work/tasks/3605/139283605/python3{,-{libs,devel,tkinter,idle}}-3.14.0-100.fc43.x86_64.rpm I get it working. That should give you enough confidence to see if the funky acting is related or not. This will be released as Python 3.14.1 in 1 week. Despite the stated urgency, I don't think releasing an update with just this backport is worth it. It would still take a couple days to reach the stable repositories and I'd rather test the new release as a whole. That said, I can open a WIP pull request that should give you a more respectable scratchbuild built by Fedora CI (in case you don't want to install something I just uploaded to our build system and might be hard to verify).
(In reply to Miro Hrončok from comment #13) > Here's a build with a backport and all tests enabled: > https://koji.fedoraproject.org/koji/taskinfo?taskID=139283586 > > I am going to test it with kicad. Thanks. I can also confirm that the startup problem is fixed. Sadly, it does seem like the odd GUI delays are still there (see my comment #8), so they were indeed a separate thing and not from my hacky cpython workaround. I wonder if the F43 version of KiCad / wxWidgets was built with native Wayland support? Because that's been a known problem for a long time: KiCad does not work well with Wayland. (And that's probably not directly a KiCad bug, but simply a wxWidgets issue). Oh well.
Sorry, I cannot help you with wxWidgets, Wayland etc.
(KiCad maintainer here...) I'm glad to see that this is finally getting the attention it deserves. I'm personally keeping the machines at my location on F42 until the dust settles. I was fortunate to find out about this back on 2025-09-08 in bug https://bugzilla.redhat.com/show_bug.cgi?id=2393850, so I knew to stay on F42, and therefore had no reason to risk downgrading Fedora. Others were not so lucky. In addition to the flatpak workaround, another option is of course to set up a temporary F42 VM to run KiCad until this is resolved.
FEDORA-2025-e235793f10 (python3.14-3.14.2-1.fc43 and python3-docs-3.14.2-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-e235793f10
FEDORA-2025-e235793f10 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-e235793f10` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-e235793f10 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-e235793f10 (python3.14-3.14.2-1.fc43 and python3-docs-3.14.2-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.