Python gets killed with SEGV when it gets updated between starting the script and importing a `dnf` module (likely affects other modules, it's just I was bitten by this one). Reproducible: Always Steps to Reproduce: 1. Start python3 on Fedora 41 when python3 is at 3.13.0-1, import logging 2. Update python3 to 3.13.1-2 (or simply update everything) 3. Import dnf (likely affects also other modules that have native parts) Actual Results: Segmentation fault Expected Results: Ideally it should work. But at worst the import should fail with a message about incompatible Python version. python3-3.13.0-1.fc41.x86_64 before update python3-3.13.1-2.fc41.x86_64 after update python3-libdnf-0.73.4-1.fc41.x86_64 (python3-libdnf-0.73.4-2.fc41 is affected too)
Created attachment 2063668 [details] Minimal reproducer
Created attachment 2063669 [details] Full backtrace of a crash Crash report by coredumpctl / abrt is useless as it tries to use debug symbols for already updated python3. But launching gdb before produces good results.
I expect a question "why you don't import dnf early" or similar, so let me answer right away. The actual use case is more complicated and the `dnf update` call is actually `dnf install` of a bunch of packages, in some cases including `python3-libdnf`. And in some cases it does pull in a python3 update via dependencies. So, no, unfortunately I cannot import `dnf` earlier, because it may not be there yet...
So, you run Python. While running it, you update it, and then importing things crashes. I don't know if we can support this use case at all. Does the crash happen when you restart Python after the update? What do you suppose should happen? How should Python know this has happened?
I would expect things not to SEGV. Ideally, the ABI would not change between minor versions (3.13.0 -> 3.13.1), but that's likely unrealistic request. What I would like to happen is for Python to detect incompatible ABI and refuse to import the module, with a proper exception (ImportError?). Or maybe the issue is that the ABI theoretically is stable, but some structures that should be internal leaked to external callers? In this particular situation I do control when things are updated, so I also know why the crash happened. But I imagine many multi-user systems won't have this luxury and users will see random crashes when the admin install updates...
Ok, to reproduce, the dnf Python module is not needed: 1. install Python 3.13.0 (e.g. via dnf --repo=fedora install python3) 2. run: python3 3. press Ctrl+z 4. update Python to 3.13.1 (e.g. via dnf upgrade python3) 5. run: fg 6. do: import email.parser Segmentation fault (core dumped) Anyway, even if we attempt to fix this, we might not be bale to fix it for 3.13.0.
I have reported this upstream: https://github.com/python/cpython/issues/128341
A specific workaround for this is to statically build the _datetime module into libpython. That would prevent this exact instance of this issue. But we cannot retroactively do that for 3.13.0. For the in-place upgrade from 3.13.0, it would unfortunately present an exception, as the file would no longer exist on disk: >>> import _datetime Traceback (most recent call last): File "<stdin>", line 1, in <module> import _datetime ModuleNotFoundError: No module named '_datetime' However, modules using the datetime module (no leading underscore) would still work with the Python implementation. And it's better than a traceback. --- There is another module, _pickle, with a problem, but it's an exception and not a segfault: >>> import _pickle Traceback (most recent call last): File "<stdin>", line 1, in <module> import _pickle AttributeError: getstate I will wait a bit to see if anything more helpful comes out of the upstream ticket, however. However, we have a workaround to apply if needed. We might as well engineer an integration test to prevent this kind of problem to happen with another stdlib module in the future.
FEDORA-2025-75e0490ac7 (python3.13-3.13.1-4.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-75e0490ac7
FEDORA-2025-e3af684cc6 (python3.13-3.13.1-4.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-e3af684cc6
FEDORA-2025-6a28699d5d (python3.13-3.13.1-4.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2025-6a28699d5d
FEDORA-2025-75e0490ac7 (python3.13-3.13.1-4.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-6a28699d5d has been pushed to the Fedora 40 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-6a28699d5d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-6a28699d5d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-e3af684cc6 has been pushed to the Fedora 41 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-e3af684cc6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-e3af684cc6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-e911f71d99 has been pushed to the Fedora 41 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-e911f71d99` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-e911f71d99 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-33e7714792 has been pushed to the Fedora 40 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-33e7714792` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-33e7714792 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-e911f71d99 (python3.13-3.13.2-1.fc41 and python3-docs-3.13.2-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-33e7714792 (python3.13-3.13.2-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.