Assertion error in pool.hpp

[kilinitt]

Hello,

I get the following assertion failure:

[root@a4030d980752 /]# dnf install ./rsync-3.3.0-3.fc41.aarch64.rpm
Updating and loading repositories:
Repositories loaded.
terminate called after throwing an instance of 'libdnf5::AssertionError'
what(): libdnf5/./solv/pool.hpp:246: void libdnf5::solv::Pool::swap_considered_map(libdnf5::solv::SolvMap&): Assertion 'other_considered_map.allocated_size() == 0 || other_considered_map.allocated_size() >= get_nsolvables()' failed: The considered map is smaller than the number of solvables in the pool
Aborted (core dumped)

It happens after a specific and somewhat set of packages installed and uninstaleld as the image is built.

Once in this state, it happens with any .rpm file that i've tried installing via dnf. What information can I provide for you to be able to diagnose the problem?

libdnf5 version is: libdnf5-5.2.8.1-2.fc41

[m-blaha]

Hi,
It seems you’re able to reproduce the issue. If possible, could you share step-by-step instructions on how to reach this unfortunate state? That would be really helpful. Also getting a backtrace from the core dump might shed some light on the problem.

[kilinitt]

Hi @m-blaha, yes I have a reproducible setup, but it's actually quite difficult to detail the steps that get us to this point. I saw the problem on an intel machine as I was building an image a few days ago, and it went away as I worked on the image, so I brushed it off to docker build issues. Then it surfaced on a different image on my ARM machine, which is the reproducible case that I have. Happy to share that image with you if it can be done privately. Please let me know. I will also try to get a trace from the core dump for you later today.

[m-blaha]

Thank you. In case you are willing to share the image, you can contact me on e-mail [email protected]

[kilinitt]

I can certainly do that. Apologies it's been a hectic week. Plan to get it to you by Monday @m-blaha. Thank you.

[m-blaha]

We still don’t have a reproducer, so fixing the issue will be challenging.

Let me summarize what we have so far:

Here’s the traceback provided by the reporter:

#0  0x000071c235063114 in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x000071c235009f9e in raise () from /lib64/libc.so.6
#2  0x000071c234ff1942 in abort () from /lib64/libc.so.6
#3  0x000071c235242da9 in __gnu_cxx::__verbose_terminate_handler() [clone .cold] () from /lib64/libstdc++.so.6
#4  0x000071c235254c2c in __cxxabiv1::__terminate(void (*)()) () from /lib64/libstdc++.so.6
#5  0x000071c235242951 in std::terminate() () from /lib64/libstdc++.so.6
#6  0x000071c235254eb8 in __cxa_throw () from /lib64/libstdc++.so.6
#7  0x000071c2354e4597 in ?? () from /lib64/libdnf5.so.2
#8  0x000071c235628952 in ?? () from /lib64/libdnf5.so.2
#9  0x000071c2356215c1 in libdnf5::rpm::PackageQuery::filter_obsoletes(libdnf5::rpm::PackageSet const&, libdnf5::sack::QueryCmp) () from /lib64/libdnf5.so.2
#10 0x000071c23562c4e1 in ?? () from /lib64/libdnf5.so.2
#11 0x000071c2355d1323 in libdnf5::repo::RepoSack::add_cmdline_packages(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool) () from /lib64/libdnf5.so.2
#12 0x000071c235534d0b in ?? () from /lib64/libdnf5.so.2
#13 0x000071c235535c2c in libdnf5::Goal::resolve() () from /lib64/libdnf5.so.2
#14 0x0000612a21fccbe0 in ?? ()
#15 0x000071c234ff3248 in __libc_start_call_main () from /lib64/libc.so.6
#16 0x000071c234ff330b in __libc_start_main_impl () from /lib64/libc.so.6
#17 0x0000612a21fcfb65 in _start ()

I checked the sources, and I believe this is the code path leading to the assertion error.
(Since I don’t have a reproducer, this traceback was generated by artificially adding an always-failing assertion into the libdnf5::solv::Pool::swap_considered_map function.)

#0  0x00007f61e34a8014 in __pthread_kill_implementation () at /lib64/libc.so.6
#1  0x00007f61e344ef1e in raise () at /lib64/libc.so.6
#2  0x00007f61e3436902 in abort () at /lib64/libc.so.6
#3  0x00007f61e36a5da9 in __gnu_cxx::__verbose_terminate_handler() [clone .cold] () at /lib64/libstdc++.so.6
#4  0x00007f61e36b7c4c in __cxxabiv1::__terminate(void (*)()) () at /lib64/libstdc++.so.6
#5  0x00007f61e36a5951 in std::terminate() () at /lib64/libstdc++.so.6
#6  0x00007f61e36b7ed8 in __cxa_throw () at /lib64/libstdc++.so.6
#7  0x00007f61e3d07456 in libdnf5::solv::Pool::swap_considered_map (this=0x21575f30, other_considered_map=...) at ../../libdnf5/solv/pool.hpp:247
#8  0x00007f61e3d0370a in libdnf5::rpm::PackageSack::Impl::make_provides_ready (this=0x214a7540) at ../../libdnf5/rpm/package_sack.cpp:88
#9  0x00007f61e3ceddf1 in libdnf5::rpm::PackageQuery::filter_obsoletes (this=0x7fff9e105500, package_set=..., cmp_type=libdnf5::sack::QueryCmp::EQ)
    at ../../libdnf5/rpm/package_query.cpp:2104
#10 0x00007f61e3d03db3 in libdnf5::rpm::PackageSack::Impl::load_versionlock_excludes (this=0x214a7540) at ../../libdnf5/rpm/package_sack.cpp:142
#11 0x00007f61e3d04b74 in libdnf5::rpm::PackageSack::Impl::load_config_excludes_includes (this=0x214a7540, only_main=false) at ../../libdnf5/rpm/package_sack.cpp:255
#12 0x00007f61e3d062b4 in libdnf5::rpm::PackageSack::load_config_excludes_includes (this=0x21447958, only_main=false) at ../../libdnf5/rpm/package_sack.cpp:520
#13 0x00007f61e3c61fa1 in libdnf5::repo::RepoSack::add_cmdline_packages (this=0x21447870, paths=std::vector of length 1, capacity 1 = {...}, calculate_checksum=false)
    at ../../libdnf5/repo/repo_sack.cpp:287
#14 0x00007f61e3acb081 in libdnf5::Goal::Impl::add_paths_to_goal (this=0x2145a560) at ../../libdnf5/base/goal.cpp:2989
#15 0x00007f61e3acc0d0 in libdnf5::Goal::resolve (this=0x21652d60) at ../../libdnf5/base/goal.cpp:3122
#16 0x00000000005a559f in main (argc=4, argv=0x7fff9e106fd8) at ../../dnf5/main.cpp:1434

[m-blaha]

Here are the conditions required (but not sufficient) to trigger the issue:

• A command-line RPM file is passed to the DNF5 command (e.g., dnf install ./rsync-3.3.0-3.fc41.aarch64.rpm).
• Version lock is configured with a valid configuration - confirmed with the reporter that they are indeed using version lock.