Description of problem: dnf.Base.query().available().filter(name=n, version=v, release=r, arch=a) segfaults in f21 Version-Release number of selected component: python3-3.4.1-14.fc21 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: python3 dnf-test.py crash_function: dataiterator_find_keyname executable: /usr/bin/python3.4 kernel: 3.16.1-301.fc21.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (10 frames) #0 dataiterator_find_keyname at /usr/src/debug/libsolv/src/repodata.c:1394 #1 dataiterator_step at /usr/src/debug/libsolv/src/repodata.c:1541 #2 filter_dataiterator at /usr/src/debug/hawkey/py3/src/query.c:284 #3 compute at /usr/src/debug/hawkey/py3/src/query.c:805 #4 hy_query_run_set at /usr/src/debug/hawkey/py3/src/query.c:1202 #5 run at /usr/src/debug/hawkey/py3/src/python/query-py.c:312 #6 call_function at /usr/src/debug/Python-3.4.1/Python/ceval.c:4239 #7 PyEval_EvalFrameEx at /usr/src/debug/Python-3.4.1/Python/ceval.c:2853 #8 PyEval_EvalCodeEx at /usr/src/debug/Python-3.4.1/Python/ceval.c:3607 #9 fast_function at /usr/src/debug/Python-3.4.1/Python/ceval.c:4363
Created attachment 937429 [details] File: backtrace
Created attachment 937430 [details] File: cgroup
Created attachment 937431 [details] File: core_backtrace
Created attachment 937432 [details] File: dso_list
Created attachment 937433 [details] File: environ
Created attachment 937434 [details] File: exploitable
Created attachment 937435 [details] File: limits
Created attachment 937436 [details] File: maps
Created attachment 937437 [details] File: open_fds
Created attachment 937438 [details] File: proc_pid_status
Created attachment 937439 [details] File: var_log_messages
Created attachment 937440 [details] minimal dnf base class
Created attachment 937441 [details] example to reproduce issue
It look like that .filter blows up when used to filter packages based on name, arch, version & release in f21 I have made i little test script to reproduce the issue download attached base.py & dnf-test.py and run it with sudo python3 dnf-test.py the following dnf related packages was used: dnf.0.6.1-1.fc21.noarch hawkey.0.5.0-2.fc21.x86_64 librepo.1.7.5-2.fc21.x86_64
Created attachment 937445 [details] script to reproduce the issue
Made the reproducer script a little simpler
Looking.
Odd, possibly related to other corrupted cachefile bugs (bug 1139398, bug 1131328). The crash happens when hawkey narrows packages down to those with x86_64 architecture using libsolv's dataiterator: that is a fairly common operation and I do not believe it is specific in any way to the attached script. Tim, do you happen to have the full core file? Can you reproduce this consistently? If you can: please upload the /var/cache/dnf file somewhere for us, then remove the cache files and try again. It should work then (and thus confirm my suspicion about libsolv cache corruption). Thanks!
Yes, I can reproduce this consistently on multiple f21 systems If I delete /var/cache/dnf, the script will run one time without errors next time I get errors again. I will upload /var/cache/dnf to dropbox and post a link, when the upload complettes. where do I find the full core file on my system ?
upload tarball of /var/cache/dnf here https://www.dropbox.com/sh/gofe95ogsz6gvud/AAD56gFRvHszCEHS1wH7DMsta?dl=0
I can reproduce using dnf cli also $ sudo dnf list dnf-0.6.1-1.fc21 will crash If I do a 'sudo rm -rf /var/cache/dnf', then I can run the command one time and it works, next time it craches.
I have upload a tarball of the abrt files from dnf cli crash to the dropbox link above.
also uploaded a dnf-cache-x86_64.tar.gz file containing the /var/cache/dnf on the crash time.
(In reply to Tim Lauridsen from comment #21) > I can reproduce using dnf cli also > > $ sudo dnf list dnf-0.6.1-1.fc21 > > will crash > > If I do a 'sudo rm -rf /var/cache/dnf', then I can run the command one time > and it works, next time it craches. Awesome, this reproduces it for me. Thanks!
The core of the issue is heap corruption caused by receiving unexpected EVR data (from updateinfo solvables) in pool_split_evr(). The kicker is that Radek Holy has already fixed this upstream in 7f06256, but we haven't realized the issue was this severe, haven't made a build yet and, even worse, didn't see it occurring in internal testing. I'm going to provide new builds today for rawhide and F21 devel branch. F20 is not affected as hawkey doesn't read updateinfo there.
*** Bug 1141309 has been marked as a duplicate of this bug. ***
hawkey-0.5.1-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/hawkey-0.5.1-1.fc21
Fixes the issue for me, thanks :)
Package hawkey-0.5.1-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing hawkey-0.5.1-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-11102/hawkey-0.5.1-1.fc21 then log in and leave karma (feedback).
hawkey-0.5.1-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.