Bug 428542 - Deluge UI becomes unresponsive in updating network traffic
Deluge UI becomes unresponsive in updating network traffic
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: deluge (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Peter Gordon
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-12 20:21 EST by Andrew Farris
Modified: 2008-01-22 11:00 EST (History)
0 users

See Also:
Fixed In Version: 0.5.8.1-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-20 23:19:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
backtrace log (45.47 KB, text/plain)
2008-01-13 05:01 EST, Andrew Farris
no flags Details
screenshot, notice clock time and network graph (171.81 KB, image/png)
2008-01-13 05:02 EST, Andrew Farris
no flags Details
screenshot, notice clock time and network graph are both different, deluge connection speeds all show the same (177.09 KB, image/png)
2008-01-13 05:02 EST, Andrew Farris
no flags Details
changed packages, jan 12 - 13 (4.71 KB, text/plain)
2008-01-15 21:02 EST, Andrew Farris
no flags Details
new backtrace, thread 1 is similar but last frames differ (9.33 KB, text/plain)
2008-01-15 21:22 EST, Andrew Farris
no flags Details

  None (edit)
Description Andrew Farris 2008-01-12 20:21:40 EST
Description of problem:
Deluge UI becomes unresponsive in updating network traffic, connected peers,
graphs, etc... but the UI still responds to user input (menus, context menu by
right click).

Version-Release number of selected component (if applicable):
0.5.8-1.fc8

How reproducible:
Consistent, happens 2-3 mins after application startup.

Steps to Reproduce:
1. open deluge, allow existing torrents (2 seeding, 1 leeching) to check and
begin accepting peers
2. wait 2-3 minutes with deluge window open
3. peers drop connections, transfers stop, but window does not update...
continues to show transfer speeds as they were, peer connection numbers do not
change, graphs stop updating

I'm grabbing the updates-testing 0.5.8-3 now to see if it reproduces with that.
Comment 1 Andrew Farris 2008-01-12 20:25:29 EST
There was a repeated (shows up every 3-5 minutes while deluge was unresponsive)
kernel message that may apply:

localhost kernel: possible SYN flooding on port 6881. Sending cookies.
Comment 2 Andrew Farris 2008-01-12 20:34:14 EST
Absolutely still reproduced.  The peer connections are maintained only for the
overhead traffic, but no data is moving either way, for seed or leech torrents.
 After the UI stops updating traffic drops from the average 20kb/s both
directions down to sub-1kb/s both directions.

Netstat shows many open connections, but deluge UI is not showing them changing
while netstat is.
Comment 3 Andrew Farris 2008-01-12 20:36:12 EST
CPU history is also pegged at 100% until deluge is quit (does not have to be
killed, just file->quit).
Comment 4 Andrew Farris 2008-01-12 21:48:07 EST
Ok this may have been nothing more than a corrupt torrent.  I removed the
torrent being leeched (kept the 2 seeds active) and restarted deluge, the seeds
worked fine.  I then added the leech back in (downloading the .torrent again,
but keeping the same partial downloaded data) and its running fine almost an
hour later.  I closed and restarted deluge a few times and cannot reproduce the
problem.

The SYN flood kernel message is no longer occurring.

Was strange behavior for the program though, not fully locking up to input but
not refreshing the window either.

Unless anyone sees a reason to keep this open, I suppose it should close
insuffucient data?
Comment 5 Peter Gordon 2008-01-12 23:14:57 EST
I'm closing this as WORKSFORME, as you no longer appear to be receiving the
error and I cannot reproduce it with brief testing. Please re-open it if the
issue persists with future versions.

Thanks for the detailed bug report!
Comment 6 Andrew Farris 2008-01-13 05:01:07 EST
Well.. its back.  The same set of torrents, but at a different point in the
downloaded data.  I stopped the torrent for a few hours, doing other things,
then fired it back up, and sometime later it was frozen the same as before.

I've got the attached backtrace showing 6 threads, though gdb starting has alot
of messages about missing symbols (and I had to install the deluge-debuginfo rpm
after it was already running and frozen).  I don't know how effective that bt
is, but let me know.

After the bt in all threads, I let deluge continue for about a minute,
interrupted and bt'd, then did it again for another minute, and bt.  It seems to
be stuck in the same spot that whole time, unless that bit of code is called
frequently and it just was circumstance I interrupted there.

I decided to leave deluge alone (quit but torrents and data as they were) in
that state until you let me know if any other info could be useful, so not going
to delete and restart the torrent like before yet.  I'll download the file on
another machine in the meantime.  If you can get back to me in a few days I
should be able to further look into why its hanging here.
Comment 7 Andrew Farris 2008-01-13 05:01:48 EST
Created attachment 291492 [details]
backtrace log
Comment 8 Andrew Farris 2008-01-13 05:02:16 EST
Created attachment 291493 [details]
screenshot, notice clock time and network graph
Comment 9 Andrew Farris 2008-01-13 05:02:53 EST
Created attachment 291494 [details]
screenshot, notice clock time and network graph are both different, deluge connection speeds all show the same
Comment 10 Andrew Farris 2008-01-13 05:07:41 EST
The screenshots have a blank area in the middle blocking upload speed, but its
the same in both shots (gnome-screenshot utility issue).

Also the end of the backtrace shows those kernel messages occurring again, SYN
flood.  My iptables setup also starts spewing lots of invalid state traffic as
soon as this happens, so deluge is not responding properly to the traffic.
Comment 11 Peter Gordon 2008-01-14 01:27:11 EST
Gaahh. Deluge uses a SVN snapshot of libtorrent internally; and there was a fix
committed recently for some infinite looping in the bandwidth_manager code. I'll
look into this tomorrow after class; I believe that could be a potential cause
for this bug.
Comment 12 Peter Gordon 2008-01-14 23:49:00 EST
The backtrace is very helpful in trying to pin down the cause. Thanks for that.

I wonder though: You said that it may have been a corrupt torrent at first; and
removing it seemed to "fix" the issue for the time being. When the error
persisted, was it the same torrent that caused it? Do other torrents (from the
same tracker) work fine? 
Comment 13 Andrew Farris 2008-01-15 02:11:08 EST
Well.. thats a bit of an assumption on my part.  The leeching torrent was new that day and so I assume 
thats what changed, by adding that torrent.  The two seeds had been there, running part of every day 
for a couple weeks and I didn't notice this issue (but cannot guarantee it didn't happen).  I don't know if 
I had updated deluge while those seeds were already opened.

The guess at corrupt torrent was just because the problem went away temporarily just after I deleted 
the torrent and started it again, opening off the tracker list.  I kept the same partial data when I did 
that.

All those 3 torrents are on the same tracker, the fedora tracker at duke, and I've never had any 
problems connecting to it or running torrents with it.  All those 3 torrents are now seeding off the same 
machine that has deluge problems, but right now seeding with transmission and no issues with that.

So, it was only 5-6 times that I've seen deluge 'lockup' like this, and it was always with that rawhide 
torrent file leeching.  I have the data now so I could try it with this deluge version while seeding, or 
leeching, and see what happens (maybe tomorrow I can do that).
Comment 14 Peter Gordon 2008-01-15 02:52:17 EST
(In reply to comment #13)
> So, it was only 5-6 times that I've seen deluge 'lockup' like this, and it was
always with that rawhide 
> torrent file leeching.  I have the data now so I could try it with this deluge
version while seeding, or 
> leeching, and see what happens (maybe tomorrow I can do that).

I would greatly appreciate you doing that for me. It'd help at least eliminate a
possible cause. Please let me know of your results; especially if the hanging
occurs more or less frequently, if the backtrace is still the same, etc.

Thanks very much.

Comment 15 Andrew Farris 2008-01-15 21:02:01 EST
Today I was unable to trigger this bug in a few hours testing either by seed or
leech on that torrent, or others.  There is a slight complication here.. I had a
large number of updates-testing changes on the 13th, but had not logged out or
restarted.

Attached is the list of packages changed between when I first noticed this bug
and now, is there any chance one of these effected the bug?
Comment 16 Andrew Farris 2008-01-15 21:02:30 EST
Created attachment 291790 [details]
changed packages, jan 12 - 13
Comment 17 Andrew Farris 2008-01-15 21:22:06 EST
Created attachment 291791 [details]
new backtrace, thread 1 is similar but last frames differ

Ok, every time I think I can't break it...
Deluge was running nicely, the rawhide torrent was downloading, other 2 seeding
as before.  I quit deluge, and 10s later opened it again, and this time no
window appears and the cpu pegs to 100%.  This bt was taken then, deluge has
not fully opened or drawn any UI yet here.

After killing deluge, I opened it again and it ran for about 30s (just finished
checking torrents) and it locked again.  (2 seeds, 1 leech) and this backtrace
is exactly the same for thread 1 as the first backtrace.

Removed rawhide torrent, changed to all 3 seeding data, quit and reopened.  The
same happened, lockup just after finishing checking torrents and accepting a
few connections (it starts sending data, then breaks off very soon after). 
With all 3 seeding I have the same backtrace as first posted.

#0  0x00110402 in __kernel_vsyscall ()
#1  0x00a9bac3 in poll () from /lib/libc.so.6
#2  0x00259623 in ?? () from /lib/libglib-2.0.so.0
#3  0x00259999 in g_main_loop_run () from /lib/libglib-2.0.so.0
#4  0x04e5b3ea in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0

It happens both seeding and leeching.
Comment 18 Andrew Farris 2008-01-15 21:24:08 EST
I seeded these same 3 torrents through transmission all night long last night
without any issues as well, same tracker, and uploaded the expected amount of data.
Comment 19 Peter Gordon 2008-01-18 19:53:34 EST
None of those packages, at first glance, really seems like it would be the cause
of these errors. (libupnp might be suspect, but Deluge doesn't use that library).

Thanks for the backtraces. I will leave Deluge running some of these torrents
overnight for the next night or two and attempt to reproduce the hang.
Comment 20 Andrew Farris 2008-01-18 20:16:53 EST
I will repeat attempts to hang it as well tonight and tomorrow to verify its happening to me (not some 
transient network issue that has disappeared when you're trying).  If you have any other debugging 
suggestions / requests I can help with a little guidance in what to look for (since I don't know the code 
base), though I'm a cpe major and comfortable with gdb if I know what to dig for.  Email direct if getting 
on irc or chat (or knowing my seed ip) will help you solve this one.
Comment 21 Peter Gordon 2008-01-20 01:38:40 EST
Hmm, unfortunately I was able to make it hang overnight yesterday, but since
then it has not happened again. Although when it DID happen, the backtrace was
about the same, so at least I know it IS reproducable...though HOW I'm still
confused on.

I recently built 0.5.8.1, which is in the queue to be pushed to updates-testing.
When it hits the repository, could you please attempt to reproduce this with the
new version? There was a large libtorrent sync between 0.5.8 and the point-one
release, and I believe some of the bandwidth_limit separations may fix this issue.

Thanks.
Comment 22 Andrew Farris 2008-01-20 16:19:36 EST
I pulled the package out of koji and am testing today.
Comment 23 Andrew Farris 2008-01-20 23:19:20 EST
This appears to be fixed in 0.5.8.1-1.

After updating I tried various download and upload rate limits for the app
overall and individual torrents, added other torrents both seeding/leeching, and
cannot hang it.

Downgraded back to 0.5.8-3 the hang happened within minutes using the same
configuration and torrents, then updated again and no problem.

Looks like this issue is done for now at least.
Comment 24 Fedora Update System 2008-01-22 10:50:29 EST
deluge-0.5.8.1-1.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update deluge'
Comment 25 Fedora Update System 2008-01-22 11:00:15 EST
deluge-0.5.8.1-1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update deluge'

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