Created attachment 1489793 [details] screenshot of dnf being run and failing Description of problem: Running dnf crashes after go to various repos. See the screenshot. Version-Release number of selected component (if applicable): dnf ver 3.5.1 rpm ver 4.14.2 How reproducible: Not able to reproduce on other systems Steps to Reproduce: 1. Fedora 29 beta 2. dnf update -y 3. <fails>
Could you attach a backtrace or coredump? Or create a reproducer in a docker image or another clean environment? Otherwise we don't have sufficient information to fix the issue.
How could I trigger a coredump? Harish
Just follow: su -c 'echo "core.%e.%p" > /proc/sys/kernel/core_pattern' Then run app that fails. The coredump will be created in present directory and will look like core.dnf.9299 Please than attach the file. Thanks a lot.
Thanks (In reply to Jaroslav Mracek from comment #3) > Just follow: > su -c 'echo "core.%e.%p" > /proc/sys/kernel/core_pattern' > > Then run app that fails. > > The coredump will be created in present directory and will look like > core.dnf.9299 > > Please than attach the file. Thanks a lot. Excellent. Thanks for the tip. I just ran it and will attach the file, in my case, core.dnf.8295. The original file was over 200M in size and it is now gzipped to 70M. Since there is a file size limit to uploading here, I am placing it on my personal server and the link is: https://temasek.net/core.dnf.8295.gz. I will delete the file at 2359UTC 31 October 2018 unless I am told otherwise.
I tried to open it and I got only: #0 0x00007f2828cd812b in std::vector<std::shared_ptr<libdnf::TransactionItem>, std::allocator<std::shared_ptr<libdnf::TransactionItem> > >::push_back (__x=..., this=0x56145ed3be78) at /usr/include/c++/8/bits/stl_vector.h:1074 1074 push_back(const value_type& __x) Missing separate debuginfos, use: dnf debuginfo-install libnghttp2-1.32.1-1.fc29.x86_64 openssl-libs-1.1.1-0.pre9.3.fc29.x86_64 pcre2-10.31-11.fc29.x86_64 (gdb) bt #0 0x00007f2828cd812b in std::vector<std::shared_ptr<libdnf::TransactionItem>, std::allocator<std::shared_ptr<libdnf::TransactionItem> > >::push_back(std::shared_ptr<libdnf::TransactionItem> const&) (__x=<error reading variable: Cannot access memory at address 0x56140000000a>, this=0x56145ed3be78) at /usr/include/c++/8/bits/stl_vector.h:1074 #1 0x00007f2828cd812b in libdnf::TransactionItem::addReplacedBy(std::shared_ptr<libdnf::TransactionItem>) (value=<error reading variable: Cannot access memory at address 0x2f83d0fa8>, this=0x56145ed3be10) at /usr/src/debug/libdnf-0.20.0-1.git.2339.9a49e9e.fc29.x86_64/libdnf/transaction/TransactionItem.hpp:113 #2 0x00007f2828cd812b in libdnf::Transformer::transformRPMItems(std::shared_ptr<SQLite3>, std::shared_ptr<SQLite3>, std::shared_ptr<libdnf::TransformerTransaction>)Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x0: (this=<optimized out>, swdb=#3 0x000056145f8a0130 in () #4 0x0000000000000008 in () #5 0x00007f282865d383 in sqlite3_free (p=0x56145dde98e8) at sqlite3.c:26205 Please can you try to run "sudo gdb /usr/bin/python3.7 core.dnf.8295" and message about missing packages appears. Please exit and install missing debug packages. Please repeat it several times ("sudo gdb /usr/bin/python3.7 core.dnf.8295" and run hint dnf command) till dnf says nothing to do. Then please run "sudo gdb /usr/bin/python3.7 core.dnf.8295" and then use "bt" command. The output please save and attach here. Thanks a lot.
I am working on this.
There are missing packages being reported. Asked to "dnf debuginfo-intall python3-3.7.0.9.fc29.x86_64. But that fails as expected with "Segmentation fault". There is a new core.dnf.28186 file. and running that with the command above, as expected, fails. I might have to a fresh install of F29 instead.
Please can you download dnf, libdnf, dnf-plugins-core(if needed), dnf-plugins-extras(if needed), libsolv and their relevant subpackages and update the system using rpm (rpm -U <package_file.rpm,...>) Please download relevant packages from: https://koji.fedoraproject.org/koji/buildinfo?buildID=1166318 https://koji.fedoraproject.org/koji/buildinfo?buildID=1166316 https://koji.fedoraproject.org/koji/buildinfo?buildID=1166330 https://koji.fedoraproject.org/koji/buildinfo?buildID=1166329 https://koji.fedoraproject.org/koji/buildinfo?buildID=1171217 Hope that it solves your problem
I am sorry but without additional data we cannot find a root of the issue.