What filesystem are you downloading to ?

Ext3 (not root, it's mounted at /media/data).

In the advanced settings, there is a parameter named GUI update interval, could you try setting that to 2 seconds ?

I've already done that...

Is there any easy way for me to check which method in which class causes this? With, I don't know, gdb or some profiler?... That would help you a bit, right? But you would have to give me instructions how to do this :)

Have you ever worked with gprof ?

You would have to recompile with the -pg compiler option and then when you run ktorrent a file named gmon.out will be generated, which you then use with gprof to generate a listing of all the functions and how much time was spent in each of them. Some more details :

http://www.cs.utah.edu/dept/old/texinfo/as/gprof_toc.html

Note, if you do this, run with the --nofork option.

I have this problem on edgy with ktorrent 2.1 too. Sometimes if a download is ready, the cpu usage of ktorrent increases, the little icon on tray disappear, the tooltip window with the message that the download is ready is empty and ktorrent quits.

Created attachment 19859 [details]
gprof output, 1st run

Output from gprof analysis of 1st run of ktorrent - when ktorrent was running
for some short time and didn't do anything bad (for comparison with the other
runs).

Created attachment 19860 [details]
gprof output, 2nd run

Gprof output, 2nd run - ktorrent was running for the whole bloody day since
morning, and only at 1am it started using 100% of cpu (and was closed by me
shortly after that).

Created attachment 19861 [details]
gprof output, 3rd run

Gprof output, 3rd run - ktorrent was running for about half an hour normally,
then for about half an hour it was running with 100% cpu usage (i had to close
it in the end, because my cpu was overheating...). It seems that once it gets
to the "100% cpu" state, it's starts doing that much faster after it's closed
and started again. It may be some state of the torrents causing that...

At first glance, I'm not seeing much stick out, but I need to further analyze it. 

We have just released 2.1.1, could you try that release, there have been some significant changes in the networking code, which hopefully will fix this bug.

Created attachment 19978 [details]
output of gdb running ktorrent, part 1

Created attachment 19979 [details]
output of gdb running ktorrent, part 2

details below

Well, I've been testing it for a few days, and: the bad news is that the bug is still there; and the good news is that I have an idea where it may be. I tried running ktorrent 2.1.1, and when it started to go crazy, I paused it and looked at the backtrace (logs attached above), resumed, paused again, etc. I noticed that there was a lot of "dht::" there, especially during the second session. So then I went to preferences while it was running at 100% cpu and unchecked General->DHT->Use DHT to get additional peers. It helped instantly, the cpu usage was down to the normal level. I changed it back and repeated this a few minutes later with the same effect. So the bug must be somewhere in the DHT module, I hope the logs help you - if not, I can make more of them...

It would be interesting to know how many DHT packets you are getting per second. I'm thinking the amount of packets you are getting is rather high, and KT doesn't handle this properly.

I'm gonna run some tests, and simulate a high DHT packet load.

Can you post the log file of ktorrent (~/.kde/share/apps/ktorrent/log) of a session with DHT enabled and this high CPU load ?

I have made a fix in the current SVN version which cuts down the CPU usage in case of high DHT packet load. Can you try that and see if it is better.

I've looked at a log from 2.1.1 - it's got 91 MB (after half an hour of running) and it's mostly "DHT: Sending ping response" a few hundred times per second. (I wonder, maybe it is just the logging what causes the high cpu usage? :)

I'm going to try the SVN version later today or tomorrow.

The logging shouldn't have that much impact.

Somebody seems to continuously sending DHT pings to you. The latest SVN handles high packet loads better. We cannot make the pings go away, but we can handle them faster.

I've tried the version from SVN from 18.03, but still no change. And you were right, it's not just logging - I commented out the line that prints "sending ping response" and that also changed nothing.

CPU usage should go down a bit, unless you are getting a huge amount of ping packets. Could you run ethereal, so we can see where these packets are coming from ?

Only capture UDP packets (DHT uses UDP)

Hmm... that's strange...

I forgot to tell you that I'm behind a NAT :) I have port forwarding on my server, so tcp & udp ports 6881 on the server are forwarded to tcp & udp ports 6881 on my computer. Now, when I run ethereal on the server on the external eth, I get only about 20 pings per second (from various addresses). But when I run it on the internal eth, I get about 500 per second. So it seems that all those bad pings come from my server... I'm not sure what to think about this, but can there be some feedback loop which causes ktorrent on my computer to reply to pings that come from itself?... And if it's all because of some error in my configuration, then why this only happens after some time, not immediately after ktorrent's start?

Oh, and I don't have any bittorrent clients or servers on the router computer (I think).

---

I don't know if this matters but here are parts of my firewall file which are relevant to the forwarding (I use a firewall generated by this script: http://easyfwgen.morizot.net/gen/):

$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 6881 -j ACCEPT
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 6881 -j ACCEPT

$IPT -A FORWARD -p tcp -i $INET_IFACE --destination-port 6881 --destination 10.1.1.21 -j ACCEPT
$IPT -A FORWARD -p udp -i $INET_IFACE --destination-port 6881 --destination 10.1.1.21 -j ACCEPT

$IPT -t nat -A PREROUTING -p tcp -i $INET_IFACE --destination-port 6881 \
     -j DNAT --to-destination 10.1.1.21
$IPT -t nat -A PREROUTING -p tcp -i $LOCAL_IFACE --destination-port 6881 \
     --destination $INET_ADDRESS -j DNAT --to-destination 10.1.1.21
$IPT -t nat -A PREROUTING -p udp -i $INET_IFACE --destination-port 6881 \
     -j DNAT --to-destination 10.1.1.21
$IPT -t nat -A PREROUTING -p udp -i $LOCAL_IFACE --destination-port 6881 \
     --destination $INET_ADDRESS -j DNAT --to-destination 10.1.1.21

I don't have any firewall on the desktop computer (I don't need one, at least in Linux, as I have a firewall on the server...).

I'm not an iptables expert, but these 2 rules : 

$IPT -t nat -A PREROUTING -p tcp -i $LOCAL_IFACE --destination-port 6881 \
     --destination $INET_ADDRESS -j DNAT --to-destination 10.1.1.21

$IPT -t nat -A PREROUTING -p udp -i $LOCAL_IFACE --destination-port 6881 \
     --destination $INET_ADDRESS -j DNAT --to-destination 10.1.1.21 

Wouldn't that forward all pings KT does (which would arrive on $LOCAL_IFACE) to port 6881 back to your local PC ?

Only if those pings had the outside address of the router ($INET_ADDRESS = 213.134.183.78) set as destination, I think - and they shouldn't, as there's no bittorrent client on the router - they should be addressed to some peer's IP, am I right? Unless ktorrent really intends to ping the router for some reason...

That's theory, and in practice I can see a few peers with IP 213.134.183.78 (4 out of 22 total at the moment) in the list in the "peers" tab (the one with flags), I don't know why. So that could be the problem - peers with my IP get somehow on the list, ktorrent tries to ping them and the router sends the pings back to me...

Wait - is it possible, as ktorrent doesn't know now it's really running on 213.134.183.78, and thinks it runs only on 10.1.1.21, that it sometimes finds the outside address through the search procedure which it uses to find other peers, finds that this peer (which is itself) has a part of the file downloaded (of course it does), and tries to connect to it? So to solve this, ktorrent should either automatically find if it's behind a NAT and what it's external IP is (if it's possible), and don't try to connect to that IP, or allow the user to enter the IP manually... am I thinking correctly?

Correction - the peers with my external IP which I see on the peers list is not my ktorrent trying to download from itself - they have BitComet and µTorrent in the "client" column...

KT drops connections to itself during the handshake (ie we compare the peer id we get with our own, if it is equal we drop the connection).

Those peers you are seeing with your WAN IP address, this indicates that there is something wrong with the way NAT is setup. If it is setup properly you should see the ip address of the remote peer. KT will get the address of the remote peer by looking at the source ip address in the packets, if NAT screws that up, KT has the wrong address.

This could explain the behavior with the DHT packets.

KT will automatically ping every peer, if it pings one of those peers with your WAN ip address, those packets will just be sent back to KT, because the destination address is your WAN address.

I have made sure that KT will drop DHT requests from itself.

And I've managed to fix my firewall :) I've commented out such line:

iptables -t nat -A POSTROUTING -o $LOCAL_IFACE -j SNAT --to-source $INET_ADDRESS

which apparently used to change source address of incoming packets to $INET_ADDRESS. I've checked in wireshark and it seems that it worked, and ktorrent has been running for several hours with DHT and there are no problems yet (and no more peers with my IP on the list). I only wonder if some other thing will not stop working suddenly - if that firewall generator added this line, it must have had some reason :)

Anyway, I think ktorrent shouldn't go crazy because someone has an error in their firewall, and I don't think I'm the only one who had it (see http://en.wikipedia.org/wiki/Port_forwarding "common caveats"), so it's good you've fixed this too - I'll check on the old firewall file if it works now.

Good to hear that.

Bug closed.

I've tried using old firewall settings and KTorrent 2.1.3 - I've downloaded one torrent and haven't encountered any problems, I mean there's a lot of 213.134.183.78 peers on the list, but CPU usage is normal. So everything is ok now, thanks :)

I have the same problems when downloading to an USB external FAT32 disk if the total file size of my downloads are more than 5 GB.

I can however avoid the CPU overloading by starting the torrents one at a time with a five minute wait between them.

I managed to solve the problem of one of my CPU cores being pegged by disabling UPnP plugin...