Registered Member
|
Ok, yesterday evening ktorrent closed itself with no crash report while I was out. I checked the log, and found that probably it got closed because it was hogging memory. I started KTorrent around 22:00. It seems to have closed around 00:35-00:48 because of this odd behavior:
I've stripped out the various connection and tracker messages, but nothing was out of the ordinary other than this. No torrents were downloading, only seeding. The problem seems to have started around 23:11:
And began to get bad at around 00:00 exactly:
There were no odd tracker responses or any other odd messages at all that I could see. |
Moderator
|
There is something strange going on there :
Wed Jul 30 00:32:33 2008: Grab chunk 405 (1 in memory) Wed Jul 30 00:32:39 2008: Grab chunk 405 (137 in memory) Wed Jul 30 00:32:41 2008: Grab chunk 40 (2 in memory) Wed Jul 30 00:32:43 2008: Grab chunk 488 (138 in memory) Wed Jul 30 00:32:46 2008: Grab chunk 416 (3 in memory) |
Moderator
|
|
Registered Member
|
This is still happening now that I've started KTorrent again, so I'll have plenty of logs of it if you want more.
I stared KTorrent at 11:18. It began right here at 11:32:20. A new chunk was grabbed and one cleaned at the same time, maybe this is causing the counter to be off by one chunk? If it's helpful, I can revert the changes I made to the logging (don't show grab chunk when it doesn't grab a chunk, don't show cleaning when didn't clean any chunks).
|
Moderator
|
|
Registered Member
|
|
Registered Member
|
I think I found the bug. It just happened again, at exactly the same time: midnight.
Looks like getCurrentTime() / timestamp map doesn't work for rolling over at the end of the day? Looks like you use this all over... anywhere else the end of day thing matters? Quick and dirty fix?
If that's not the exact problem, it's some other place that doesn't work over the end of the day. |
Moderator
|
|
Registered Member
|
Well.. it's happened to me exactly twice, on two consecutive days, at exactly midnight. Look back at the log I posted before: the timestamp is there. I'll add some log lines to spit out i.value() and bt::getCurrentTime() and see what the pattern is at the next end of day. |
Moderator
|
|
Registered Member
|
My log from midnight. Three peers appear to stop checking memory:
A few minutes later, I notice, and close those peers one by one while watching the log. They were the three seeds (I was also on three downloads, which I was going to try one by one if the seeds weren't the problem):
Could it be the choker_update_timer.getElapsedSinceUpdate() that breaks at the end of day? There really is nothing else interesting in the logs. In addition to the seeding vs. downloading, the torrents that broke were private, and the others weren't. I can't think of anything else. |
Registered Member
|
Ok, it's definitely the choke timer. I added this line in torrentcontrol::update():
And the output after midnight was this:
Clearly at midnight the choke timer is getting stuck at zero. |
Moderator
|
Registered users: Bing [Bot], Google [Bot], Yahoo [Bot]