![]() Registered Member ![]()
|
I've compiled a few recent SVN revs in the past few days. Today when I compiled one and installed it and then restarted KTorrent, KT went absolutely nuts. The UI never appeared, and its memory usage (RES in top, the physical memory usage alone) jumped instantly from ~40MB to 400+MB, then gradually up to over 500MB, and it kept fluctuating, but remained higher than 500MB.
I downgraded to older SVN versions that worked fine earlier today and yesterday, and got the same behavior. I downgraded to 2.1rc1, and got the same behavior. I downgraded to 2.0.3 and got the same behavior, except it was going over 600MB. I started digging for more information. I discovered the ~/.kde/share/apps/ktorrent/log file, and I dug into the torrents and removed the ones whose tracker was the last one listed in the log file. KTorrent then displayed an error dialog for every torrent I deleted, but never displayed the tray icon or main UI, and after going through all those error dialogs, it did the same crazy memory allocation thing again. I tried doing an strace, but I couldn't discern anything useful. The end, including where I have to kill KT, looks like this:
The beginning always looks like this, and I don't know if all those ENOENT errors are normal or not:
I guess that's enough of that. Finally I ran KTorrent as a different user, whose account has never run KTorrent before, and then KTorrent started normally. This is absolutely nuts. I don't know what to do except wipe out my KTorrent data directory, which would wipe out all of my torrent downloads. I've never had a problem like this before. Yesterday I enabled the RSS plugin and set up one feed and a few filters, but it has been working fine as far as I know. Surely that wouldn't cause this problem...would it? This is a strange and horrible bug. Please let me know how I can help debug and solve it, and get my downloads to work again. |
![]() Registered Member ![]()
|
|
![]() Registered Member ![]()
|
I've tried removing more torrents, but I've noticed that the last lines of the log file are always:
The problem is, I don't know which torrent those chunks are in. |
![]() Registered Member ![]()
|
(Sorry for all the posts, but I'm updating as I go.)
I still don't know which torrent is causing it, but it is a torrent. When I removed all of the tor* directories from ~/.kde/share/apps/ktorrent, KT started fine. I reran KT and when it went bonkers I killed it with the SIGSEGV signal to cause drkonqi to run. Here's the backtrace:
|
![]() Registered Member ![]()
|
That last backtrace was from 2.0.3. I recompiled SVN r621829 with full debugging symbols and here's its backtrace:
|
![]() Registered Member ![]()
|
I use backupninja daily, and I restored a backup of ~/.kde/share/apps/ktorrent from one day ago, and voila, KTorrent started up fine. I don't know what the problem is/was. At least I have most of my downloads back, but there's definitely a bug in KT somewhere, and I'd hate to be a newbie who encountered this. Luckily I have 768MB of RAM, so there wasn't as much swapping as there would be for someone with less memory. But I have an encrypted swap set up, and all the swapping did cause the CPU to become quite busy with kcryptd. :/
Please let me know if I can provide more info to help. |
![]() Moderator ![]()
|
You compiled with full debugging, and you get this :
#9 0xb7e0d224 in std::__fill<true>::fill<unsigned char*, int> () from /usr/lib/libktorrent.so.0 #10 0xb7e0d25b in std::fill<unsigned char*, int> () from /usr/lib/libktorrent.so.0 #11 0xb7e0cc0a in bt::BitSet::BitSet () from /usr/lib/libktorrent.so.0 #12 0xb7e40b26 in bt::ChunkDownload::load () from /usr/lib/libktorrent.so.0 #13 0xb7e30a82 in bt::Downloader::loadDownloads () from /usr/lib/libktorrent.so.0 #14 0xb7e3d82d in bt::TorrentControl::continueStart () from /usr/lib/libktorrent.so.0 #15 0xb7e3dc9a in bt::TorrentControl::start () from /usr/lib/libktorrent.so.0 #16 0xb7e7603d in bt::QueueManager::startSafely () from /usr/lib/libktorrent.so.0 #17 0xb7e76d3d in bt::QueueManager::start () from /usr/lib/libktorrent.so.0 #18 0xb7e77424 in bt::QueueManager::orderQueue () No parameters, no addresses of this pointers ... Seems you are loading older versions of libktorrent. Need to make sure that libktorrent and ktorrent can no longer mismatch. |
![]() Registered Member ![]()
|
I don't know what to say about that. I built and installed the latest SVN, and the package contains libktorrent. I don't understand how I could get a version mismatch.
After I finally thought the bug was gone, I left KT running overnight downloading data. When I came back to the PC, it was using 700+MB RES, and 1029MB VIRT. I killed it with -11, but this time drkonqi said that the backtrace was of no use. I'll be glad to rebuild it or whatever it takes, but I don't know how there could be a version mismatch. |
![]() Registered Member ![]()
|
|
![]() Moderator ![]()
|
|
![]() Registered Member ![]()
|
jdong, no, everything I install is either a deb from Debian or a deb built by checkinstall from the SVN build.
What I ended up doing was using dpkg to remove the ktorrent package, then I installed the 2.1rc1 package I built a while back, and now everything's fine. Soon I will try building and installing an SVN rev again and see what happens. Thanks for your help, guys. |
![]() Registered Member ![]()
|
I had some problems building the SVN, so I've still been using 2.1rc1. I left it running overnight, and when I checked it today, it was using all of my physical memory and all of my swap. htop showed 2432M of VIRT usage by KT, and while I was waiting for the kernel to finish swapping so I could actually kill KT, the RES usage of KT started at 624M and kept increasing to 662M before I was able to kill it. After it was killed, all memory and swap usage dropped down to normal levels.
I did compile it with --enable-memleak-check, but I can't find any leak.out file that was mentioned in the other thread. |
![]() Registered Member ![]()
|
|
![]() Registered Member ![]()
|
I'm sorry, I don't know how many active connections there were. I have the global connection limit set at 400. It took about ten minutes just to kill KTorrent because the system was very unresponsive with all the swapping the kernel was doing.
I got the current SVN built and installed and am using it now. Memory usage quickly went up to 194M of RES usage, but it seems to have stabilized there. I will keep an eye on it. Also, it created the ~/leak.out file, but according to ls, it hasn't been modified since KT was first launched over an hour ago. Edit: Sorry, the filesystem is ext3. |
![]() Registered Member ![]()
|
I've just had this problem with ktorrent 2.1 final tonight. I also had it with my r626973 build once, but never with beta1, which I had used for ~1 months before (I always leave ktorrent overnight). Sorry, I can't provide more specific information, because when I got up, PC was completely unresponsive spending all time heavily swapping. X was unresponsive, I couldn't even ssh to the PC running ktorrent from another machine nor login from virtual console. I managed to kill ktorrent with ALT+Sysrq+F, and then everything went back to normal (swapping stopped, tons of memory freed), so it was surely ktorrent heavily leaking memory. Debian unstable amd64; Athlon64 3000+; 1G RAM, 1GB swap; installed from unofficial ktorrent packages (so no, there is no version conflict) built by myself. If anyone interested: deb http://alioth.debian.org/~modax-guest/ktorrent/ ./ |
Registered users: Bing [Bot], Google [Bot], Yahoo [Bot]