dnf crashes randomly. It crashes on its first launch and then the issue disappears, making debugging difficult. Console display: (translated from french). Transaction Summary: Update: 65 packets Replacement: 65 packets The total size of incoming packets is 136 MiB. A download of 136 MiB is required. After this operation, an additional 21 MiB will be used (+724 MiB, -703 MiB). Is this ok [y/N]: y Segmentation fault dmesg: [ 354.736004] dnf[4462]: segfault at 0 ip 00007fb32f54e1f4 sp 00007fff579ec3e8 error 4 in libdnf5.so.2[14e1f4,7fb32f400000+229000] likely on CPU 17 (core 37, socket 0) [ 354.736013] Code: c3 90 0f 1f 40 00 f3 0f 1e fa 48 8b 07 48 8b 78 68 48 81 c7 88 00 00 00 e9 99 fa f5 ff 90 0f 1f 84 00 00 00 00 00 f3 0f 1e fa <48> 8b 16 48 89 f8 f3 0f 6f 02 0f 12 c8 0f 11 00 66 48 0f 7e cf 48 Reproducible: Sometimes Steps to Reproduce: 1. Dnf update. 2. 3.
What version of libdnf5 package do you have installed? What command did you execute to get the crash. Does it crash with different commands, e.g. "dnf makecache". Could you install debugging packages and provide a backtrace?
I have similar problems. Sometimes segfault, sometimes failed assertions, with dnf5-5.2.15.0-1.fc42.x86_64. Here is a backtrace from an assertion case: terminate called after throwing an instance of 'libdnf5::AssertionError' what(): include/libdnf5/common/weak_ptr.hpp:208: TPtr* libdnf5::WeakPtr<TPtr, ptr_owner>::operator->() const [with TPtr = libdnf5::repo::Repo; bool ptr_owner = false]: Assertion 'is_valid()' failed: Dereferencing an invalidated WeakPtr Thread 1 "dnf" received signal SIGABRT, Aborted. ... #0 0x00007ffff728111c in __pthread_kill_implementation () at /lib64/libc.so.6 #1 0x00007ffff7227afe in raise () at /lib64/libc.so.6 #2 0x00007ffff720f6d0 in abort () at /lib64/libc.so.6 #3 0x00007ffff74091b6 in __gnu_cxx::__verbose_terminate_handler() [clone .cold] () at /lib64/libstdc++.so.6 #4 0x00007ffff741eadc in __cxxabiv1::__terminate(void (*)()) () at /lib64/libstdc++.so.6 #5 0x00007ffff7408d3c in std::terminate() () at /lib64/libstdc++.so.6 #6 0x00007ffff741ed88 in __cxa_throw () at /lib64/libstdc++.so.6 #7 0x00007ffff781e1d0 in libdnf5::WeakPtr<libdnf5::repo::Repo, false>::operator->() const [clone .isra.0] [clone .cold] () at /lib64/libdnf5.so.2 #8 0x00007ffff7956ea3 in libdnf5::repo::RepoDownloader::fastest_mirror_cb(void*, LrFastestMirrorStages, void*) () at /lib64/libdnf5.so.2 #9 0x00007ffff6d0adaf in lr_fastestmirror_detailed () at /lib64/librepo.so.0 #10 0x00007ffff6d0b869 in lr_fastestmirror () at /lib64/librepo.so.0 #11 0x00007ffff6d0baea in lr_fastestmirror_sort_internalmirrorlists () at /lib64/librepo.so.0 #12 0x00007ffff6d196ab in lr_download_packages () at /lib64/librepo.so.0 #13 0x00007ffff795389e in libdnf5::repo::PackageDownloader::download() () at /lib64/libdnf5.so.2 #14 0x00007ffff78b9d98 in libdnf5::base::Transaction::download() () at /lib64/libdnf5.so.2 #15 0x000055555564146c in dnf5::Context::Impl::download_and_run(libdnf5::base::Transaction&) () #16 0x000055555558c0bf in main ()
I have the same version of dnf5 (rawhide). dnf5-0:5.2.15.0-1.fc43.x86_64
The backtrace hints it happens when downloading packages after confirming the transaction by a user. Is that right? How many packages roughly does DNF5 download when it happens? How many parallel download (max_parallel_downloads dnf.conf option) do you have configured? If you lower it to 1, does the problem disappear?
For my problem above, it was trying to download 5 packages. dnf.conf does not contain any settings, so it should be the default value (3 as in dnf.conf(5) man page). I will try to reproduce it with some installations and test setting max_parallel_downloads to 1.
This time with segmentation fault (but as the title states: this is random) and max_parallel_downloads=1 in /etc/dnf/dnf.conf: The crash (as the last) occurs directly after confirming "Is this ok [y/N]:" with "y" Thread 1 "dnf" received signal SIGSEGV, Segmentation fault. ... #0 0x00007ffff794e074 in libdnf5::repo::Repo::get_base() const () at /lib64/libdnf5.so.2 #1 0x00007ffff7956eae in libdnf5::repo::RepoDownloader::fastest_mirror_cb(void*, LrFastestMirrorStages, void*) () at /lib64/libdnf5.so.2 #2 0x00007ffff6d0adaf in lr_fastestmirror_detailed () at /lib64/librepo.so.0 #3 0x00007ffff6d0b869 in lr_fastestmirror () at /lib64/librepo.so.0 #4 0x00007ffff6d0baea in lr_fastestmirror_sort_internalmirrorlists () at /lib64/librepo.so.0 #5 0x00007ffff6d196ab in lr_download_packages () at /lib64/librepo.so.0 #6 0x00007ffff795389e in libdnf5::repo::PackageDownloader::download() () at /lib64/libdnf5.so.2 #7 0x00007ffff78b9d98 in libdnf5::base::Transaction::download() () at /lib64/libdnf5.so.2 #8 0x000055555564146c in dnf5::Context::Impl::download_and_run(libdnf5::base::Transaction&) () #9 0x000055555558c0bf in main ()
One more observation: It occurs when running with "--refresh". I was not able to reproduce without --refresh (or without automatic refresh)
For me the crash occurs directly after confirming "Is this ok [y/N]:" with "y" simply "with dnf update". dnf.conf: [main] install_weak_deps=False fastestmirror=True
Here is a crash backtrace with debug symbols installed: Thread 1 "dnf" received signal SIGSEGV, Segmentation fault. libdnf5::repo::Repo::get_base (this=0x200000002) at /usr/src/debug/dnf5-5.2.15.0-1.fc42.x86_64/libdnf5/repo/repo.cpp:416 416 return p_impl->base; #0 libdnf5::repo::Repo::get_base (this=0x200000002) at /usr/src/debug/dnf5-5.2.15.0-1.fc42.x86_64/libdnf5/repo/repo.cpp:416 #1 0x00007ffff7956eae in libdnf5::repo::RepoDownloader::fastest_mirror_cb (data=data@entry=0x55555587c0b0, stage=stage@entry=LR_FMSTAGE_INIT, ptr=ptr@entry=0x0) at /usr/src/debug/dnf5-5.2.15.0-1.fc42.x86_64/libdnf5/repo/repo_downloader.cpp:162 #2 0x00007ffff6d0adaf in lr_fastestmirror_detailed (handle=0x5555559615f0, inlist=0x5555559b8c60 = {...}, outlist=outlist@entry=0x7fffffffd3c0, err=err@entry=0x7fffffffd708) at /usr/src/debug/librepo-1.20.0-1.fc42.x86_64/librepo/fastestmirror.c:606 #3 0x00007ffff6d0b869 in lr_fastestmirror (handle=handle@entry=0x5555559615f0, list=list@entry=0x7fffffffd440, err=err@entry=0x7fffffffd708) at /usr/src/debug/librepo-1.20.0-1.fc42.x86_64/librepo/fastestmirror.c:689 #4 0x00007ffff6d0baea in lr_fastestmirror_sort_internalmirrorlists (handles=0x555555bf3b20 = {...}, err=0x7fffffffd708) at /usr/src/debug/librepo-1.20.0-1.fc42.x86_64/librepo/fastestmirror.c:802 #5 0x00007ffff6d196ab in lr_download_packages (targets=<optimized out>, flags=LR_PACKAGEDOWNLOAD_FAILFAST, err=0x7fffffffd708) at /usr/src/debug/librepo-1.20.0-1.fc42.x86_64/librepo/package_downloader.c:418 #6 0x00007ffff795389e in libdnf5::repo::PackageDownloader::download (this=<optimized out>) at /usr/src/debug/dnf5-5.2.15.0-1.fc42.x86_64/libdnf5/repo/package_downloader.cpp:261 #7 0x00007ffff78b9d98 in libdnf5::base::Transaction::download (this=this@entry=0x555555b3f030) at /usr/src/debug/dnf5-5.2.15.0-1.fc42.x86_64/libdnf5/base/transaction.cpp:421 #8 0x000055555564146c in dnf5::Context::Impl::download_and_run (this=0x555555717c80, transaction=...) at /usr/src/debug/dnf5-5.2.15.0-1.fc42.x86_64/dnf5/context.cpp:488 #9 0x000055555558c0bf in dnf5::Context::download_and_run (this=0x7fffffffdef0, transaction=<optimized out>) at /usr/src/debug/dnf5-5.2.15.0-1.fc42.x86_64/dnf5/context.cpp:616 #10 main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/dnf5-5.2.15.0-1.fc42.x86_64/dnf5/main.cpp:1537
Thanks for the details. Now I can reproduce it: $ dnf5 -y --setopt fastestmirror=true --refresh --repo=fedora upgrade dontpanic There must be --refresh option and the installed packages must be from a repository defined with a mirrorlist and fastestmirror option needs to be enabled.
Downloading ("dnf download --setopt fastestmirror=true --refresh") any not-yet-cached package also triggers it.
Give me few hours for bisecting the code.
git bisect narrowed the problematic change to these commits: 3ab181d26d2dc2fbbb2945babf6d905597a87970 Use new API for parallel downloading 08d23374117add297c0e3b68c8ef67f0c22fb833 Replace `download_metadata` API with `Add` and `Download` 674f4c4c589c526551300fb86958906cf7934b04 Update users of `RepoDownloader` to match new API 60adb9918392a30dba19dac0bc337055d4c9e113 Rework is_repomd_in_sync and is_metalink_in_sync to use new perform 5c710fb49eb0be30e16b6d60559a1609fee4b3b8 Make `RepoDownloader::perform` static and rework callbacks acfac4ef57a8566166862a57bb9501d6695fafbf Convert several of `RepoDownloader` methods that to static ones 7ca8ce053a5b61f365266733cb41a87629e16704 Extract callback data from `RepoDownloader` a88bc8e7e3d141649b9fbcf34dfc5da311835e9a Remove unused `RepoDownloader` defines 8efada9dbe01749a4a4c3a1e378d281612c0a5e3 Split `DownloadData` out of `RepoDownloader` None of the listed commits can be compiled. Code before 8efada9dbe01749a4a4c3a1e378d281612c0a5e3 works, code after 3ab181d26d2dc2fbbb2945babf6d905597a87970 is crashes. That is the bug was introduced between 5.2.13.1 and 5.2.14.0 DNF5 versions. The bug was introduced with <https://github.com/rpm-software-management/dnf5/pull/2167> pull request.
*** Bug 2383151 has been marked as a duplicate of this bug. ***
Thank you for finding the root cause. Workaround to avoid the crash is to remove/disable fastestmirror=True in /etc/dnf/dnf.conf
Upstream implemented a workaround, preventing the crash.
FEDORA-2025-9ae670b810 (dnf5-5.2.15.0-2.fc42 and librepo-1.20.0-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-9ae670b810
FEDORA-2025-fdcda3af30 (dnf5-5.2.15.0-2.fc41 and librepo-1.20.0-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-fdcda3af30
FEDORA-2025-9ae670b810 has been pushed to the Fedora 42 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-9ae670b810` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-9ae670b810 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-fdcda3af30 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-fdcda3af30` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-fdcda3af30 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-9ae670b810 (dnf5-5.2.15.0-2.fc42 and librepo-1.20.0-1.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-fdcda3af30 (dnf5-5.2.15.0-2.fc41 and librepo-1.20.0-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.