Opened 12 years ago
Closed 12 years ago
#2205 closed bug (Fixed)
Exception after removing torrent
Reported by: | Chase | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 1.3.6 |
Component: | GTK UI | Version: | 1.3.5 |
Keywords: | Cc: |
Description
Unhandled exception can occur after removing a torrent:
Unhandled error in Deferred: Unhandled Error Traceback (most recent call last): File "C:\Python26\lib\site-packages\twisted\protocols\policies.py", line 118, in dataReceived self.wrappedProtocol.dataReceived(data) File "C:\Users\Chase\pycharm projects\deluge\deluge\ui\client.py", line 183, in dataReceived d.callback(request[2]) File "C:\Python26\lib\site-packages\twisted\internet\defer.py", line 368, in callback self._startRunCallbacks(result) File "C:\Python26\lib\site-packages\twisted\internet\defer.py", line 464, in _startRunCallbacks self._runCallbacks() --- <exception caught here> --- File "C:\Python26\lib\site-packages\twisted\internet\defer.py", line 551, in _runCallbacks current.result = callback(current.result, *args, **kw) File "C:\Users\Chase\pycharm projects\deluge\deluge\ui\sessionproxy.py", line 191, in on_status return self.create_status_dict(torrent_ids, keys) File "C:\Users\Chase\pycharm projects\deluge\deluge\ui\sessionproxy.py", line 106, in create_status_dict sd[torrent_id] = dict([(x, y) for x, y in self.torrents[torrent_id][1].iteritems() if x in keys]) exceptions.KeyError: '5ff038bbac132fe3b9b4e2f38293d548ed5b853d'
Change History (5)
comment:1 by , 12 years ago
Component: | other → gtkui |
---|---|
Milestone: | Future → 1.3.6 |
Version: | other (please specify) → 1.3.5 |
comment:2 by , 12 years ago
comment:3 by , 12 years ago
It seems like a race condition between one (or same?) ui deleting and another's regular call to get_torrents_status still containing the deleted torrent id.
This should prevent the error:
-
deluge/ui/sessionproxy.py
diff --git a/deluge/ui/sessionproxy.py b/deluge/ui/sessionproxy.py index 88a77e9..660cd31 100644
a b def create_status_dict(self, torrent_ids, keys): 102 102 """ 103 103 sd = {} 104 104 for torrent_id in torrent_ids: 105 if keys: 106 sd[torrent_id] = dict([(x, y) for x, y in self.torrents[torrent_id][1].iteritems() if x in keys]) 107 else: 108 sd[torrent_id] = dict(self.torrents[torrent_id][1]) 105 if torrent_id in self.torrents: 106 if keys: 107 sd[torrent_id] = dict([(x, y) for x, y in self.torrents[torrent_id][1].iteritems() if x in keys]) 108 else: 109 sd[torrent_id] = dict(self.torrents[torrent_id][1]) 109 110 110 111 return sd 111 112 … … def find_torrents_to_fetch(torrent_ids): 194 195 to_fetch = [] 195 196 t = time.time() 196 197 for torrent_id in torrent_ids: 197 torrent = self.torrents[torrent_id] 198 if t - torrent[0] > self.cache_time: 199 to_fetch.append(torrent_id) 200 else: 201 # We need to check if a key is expired 202 for key in keys: 203 if t - self.cache_times[torrent_id].get(key, 0.0) > self.cache_time: 204 to_fetch.append(torrent_id) 205 break 198 if torrent_id in self.torrents: 199 torrent = self.torrents[torrent_id] 200 if t - torrent[0] > self.cache_time: 201 to_fetch.append(torrent_id) 202 else: 203 # We need to check if a key is expired 204 for key in keys: 205 if t - self.cache_times[torrent_id].get(key, 0.0) > self.cache_time: 206 to_fetch.append(torrent_id) 207 break 206 208 207 209 return to_fetch 208 210 #-----------------------------------------------------------------------
comment:4 by , 12 years ago
When deleting a torrent there is a delay before session proxy receives the torrent_removed event so a call to get_torrents_status with the list of its known torrents including recently deleted is possible which generates a keyerror in torrentmanager.getitem (#2224), sessionproxy.create_status_dict or sessionproxy.get_torrents_status.on_status depending on the timings.
I think this fix should account for all these outcomes: https://github.com/cas--/Deluge/compare/Bug;2205;ExceptionsRemovingTorrents
comment:5 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Turns out this was already fixed in git master.
1.3-stable commits: c741e127b925e, b5ea33e50666
We could just check for the existence of the hash or catch this exception, I'd like to check what is calling this if we can fix it at a higher level though.