Bug 977661 - [abrt] Ctrl+C ends up with a TypeError traceback involving Base.__exit__() and Repo._handle_load()
Summary: [abrt] Ctrl+C ends up with a TypeError traceback involving Base.__exit__() an...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf   
(Show other bugs)
Version: 19
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ales Kozumplik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:a1b5191f842e217af8f127198c7...
Keywords:
: 986480 (view as bug list)
Depends On: 977803
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-25 06:15 UTC by Maciek Borzecki
Modified: 2014-09-30 23:41 UTC (History)
5 users (show)

Fixed In Version: hawkey-0.3.16-1.git4e79abc.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-02 03:28:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (1.41 KB, text/plain)
2013-06-25 06:15 UTC, Maciek Borzecki
no flags Details
File: core_backtrace (1.01 KB, text/plain)
2013-06-25 06:15 UTC, Maciek Borzecki
no flags Details
File: environ (3.39 KB, text/plain)
2013-06-25 06:15 UTC, Maciek Borzecki
no flags Details

Description Maciek Borzecki 2013-06-25 06:15:28 UTC
Description of problem:
Pressed ^C while dnf was updating cache

Version-Release number of selected component:
dnf-0.3.8-2.git85524ae.fc19

Additional info:
reporter:       libreport-2.1.5
cmdline:        /usr/bin/python /usr/bin/dnf info
executable:     /usr/bin/dnf
kernel:         3.9.6-301.fc19.x86_64
runlevel:       N 5
uid:            1000

Truncated backtrace:
repo.py:97:__init__:TypeError: 'NoneType' object has no attribute '__getitem__'

Traceback (most recent call last):
  File "/usr/bin/dnf", line 35, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 277, in user_main
    errcode = main(args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 48, in main
    return 1
  File "/usr/lib/python2.7/site-packages/dnf/yum/base.py", line 124, in __exit__
    self.close()
  File "/usr/lib/python2.7/site-packages/dnf/yum/base.py", line 238, in close
    self._store_persistent_data()
  File "/usr/lib/python2.7/site-packages/dnf/yum/base.py", line 166, in _store_persistent_data
    if r.metadata_expire_in()[1] <= 0]
  File "/usr/lib/python2.7/site-packages/dnf/repo.py", line 408, in metadata_expire_in
    self._try_cache()
  File "/usr/lib/python2.7/site-packages/dnf/repo.py", line 247, in _try_cache
    self.metadata = self._handle_load(handle)
  File "/usr/lib/python2.7/site-packages/dnf/repo.py", line 193, in _handle_load
    return Metadata(result, handle)
  File "/usr/lib/python2.7/site-packages/dnf/repo.py", line 97, in __init__
    self._mirrors = handle.mirrors[:]
TypeError: 'NoneType' object has no attribute '__getitem__'

Local variables in innermost frame:
res: <librepo.Result object at 0x1043ef0>
self: <dnf.repo.Metadata object at 0x10489d0>
handle: <dnf.repo._Handle object at 0x1047af8>

Comment 1 Maciek Borzecki 2013-06-25 06:15:33 UTC
Created attachment 764928 [details]
File: backtrace

Comment 2 Maciek Borzecki 2013-06-25 06:15:37 UTC
Created attachment 764929 [details]
File: core_backtrace

Comment 3 Maciek Borzecki 2013-06-25 06:15:41 UTC
Created attachment 764930 [details]
File: environ

Comment 4 Ales Kozumplik 2013-06-25 06:20:08 UTC
(In reply to Maciek Borzecki from comment #0)
> Description of problem:
> Pressed ^C while dnf was updating cache
> 

Hello,

Do you mean you pressed ^C on a previous run when DNF was downloading the cache or you pressed ^C on the run that then ended with this traceback?

Thank you!

Comment 5 Maciek Borzecki 2013-06-25 07:28:47 UTC
^C was pressed during the run that resulted in backtrace. Quick way to reproduce the problem is to run for instance 'dnf check-update' and press ^C right away, even before the names of repositories are printed. Hope that helps

Comment 6 Maciek Borzecki 2013-06-25 07:39:06 UTC
[mborzecki@COMP_006_THK_mborzecki:~]$ sudo dnf history
BDB2053 Freeing read locks for locker 0x1e25: 1071/140545094014976
BDB2053 Freeing read locks for locker 0x1e26: 1071/140545094014976
BDB2053 Freeing read locks for locker 0x1e27: 1071/140545094014976
BDB2053 Freeing read locks for locker 0x1e28: 1071/140545094014976

as a result, locks on rpm DB were not cleaned up

Comment 7 Ales Kozumplik 2013-06-25 08:37:57 UTC
Thanks!

Reproducible 3/5 times by pressing ^C 0.5s after executing a DNF command.

The traceback we are seeing is mangled, the exception is not really triggered at the time of base.__exit__. Through some experimentation I got this traceback:

^CTraceback (most recent call last):
  File "/home/akozumpl/dnf/dnf/cli/main.py", line 63, in main
    return _main(base, args)
  File "/home/akozumpl/dnf/dnf/cli/main.py", line 138, in _main
    result, resultmsgs = cli.run()
  File "/home/akozumpl/dnf/dnf/cli/cli.py", line 1295, in run
    load_available_repos=lar)
  File "/home/akozumpl/dnf/dnf/yum/base.py", line 220, in activate_sack
    self._add_repo_to_sack(r.id)
  File "/home/akozumpl/dnf/dnf/yum/base.py", line 131, in _add_repo_to_sack
    repo.load()
  File "/home/akozumpl/dnf/dnf/repo.py", line 364, in load
    if self.metadata or self._try_cache():
  File "/home/akozumpl/dnf/dnf/repo.py", line 253, in _try_cache
    self.metadata = self._handle_load(handle)
  File "/home/akozumpl/dnf/dnf/repo.py", line 198, in _handle_load
    return Metadata(result, handle)
  File "/home/akozumpl/dnf/dnf/repo.py", line 102, in __init__
    self._mirrors = handle.mirrors[:]
TypeError: 'NoneType' object has no attribute '__getitem__'

It could be some weird ^C vs. librepo interaction.

Comment 8 Ales Kozumplik 2013-06-25 11:13:31 UTC
> It could be some weird ^C vs. librepo interaction.

Which is the case indeed. Opened bug 977803.

Comment 9 Ales Kozumplik 2013-07-17 12:14:52 UTC
with bug 977803 resolved in librepo upstream this only waits for retesting and building DNF against the new version. I'll try to remember it before making the next DNF build.

Comment 10 Ales Kozumplik 2013-07-22 05:47:27 UTC
*** Bug 986480 has been marked as a duplicate of this bug. ***

Comment 11 Ales Kozumplik 2013-07-22 11:39:28 UTC
Fixed in dnf-0.3.10.

Comment 12 Fedora Update System 2013-07-22 13:17:09 UTC
hawkey-0.3.16-1.git4e79abc.fc19, dnf-0.3.10-1.giteb9dddb.fc19, librepo-0.0.5-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/dnf-0.3.10-1.giteb9dddb.fc19,librepo-0.0.5-2.fc19,hawkey-0.3.16-1.git4e79abc.fc19

Comment 13 Fedora Update System 2013-07-23 01:12:59 UTC
Package hawkey-0.3.16-1.git4e79abc.fc19, dnf-0.3.10-1.giteb9dddb.fc19, librepo-0.0.5-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing hawkey-0.3.16-1.git4e79abc.fc19 dnf-0.3.10-1.giteb9dddb.fc19 librepo-0.0.5-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-13415/dnf-0.3.10-1.giteb9dddb.fc19,librepo-0.0.5-2.fc19,hawkey-0.3.16-1.git4e79abc.fc19
then log in and leave karma (feedback).

Comment 14 Fedora Update System 2013-08-02 03:28:03 UTC
hawkey-0.3.16-1.git4e79abc.fc19, dnf-0.3.10-1.giteb9dddb.fc19, librepo-0.0.5-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.