This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Crazy allocate-600+MB memory bug!

Tags: None
(comma "," separated)
imported4-blujay
Registered Member
Posts
60
Karma
0

Crazy allocate-600+MB memory bug!

Thu Jan 18, 2007 7:02 am
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:

Code: Select all
read(4, "\0\3ICE\0\0\0 local/debian:/tmp/.ICE-"..., 4096) = 537
close(4)                                = 0
munmap(0xb7f1e000, 4096)                = 0
write(3, "\0\4\1\0\3\0\0\0\20\0\0\0\0\0\0\0\253\2741J^\375\250E\253"..., 32) = 32
read(3, "\0\10\0\2\2\0\0\0", 8)         = 8
read(3, "\3\0KDE\0\0\0\3\0002.0\0\0\0", 16) = 16
getsockopt(3, SOL_SOCKET, SO_PEERCRED, "\343\24\0\0\350\3\0\0\350\3\0\0", [12]) = 0
getuid32()                              = 1000
write(3, "\1\2\1\0H\0\0\0\0\0\0\0", 12) = 12
write(3, "\0\0\0\0\0\0\0\vDCOPServer\0\0\0\0\1\0\0\0\0\25regi"..., 53) = 53
write(3, "\0\0\0\17anonymous-6584\0", 19) = 19
read(3, "\2\3\0\0027\0\0\0", 8)         = 8
read(3, "\202\0\0\0", 4)                = 4
read(3, "\0\0\0\vDCOPServer\0\0\0\0\0\0\0\0\tQCString\0"..., 55) = 55
write(3, "\1\2\1\0^\0\0\0\202\0\0\0", 12) = 12
write(3, "\0\0\0\17anonymous-6584\0\0\0\0\vDCOPServe"..., 81) = 81
write(3, "\0\0\0\tktorrent\0", 13)      = 13
read(3, "\2\3\0\0023\0\0\0", 8)         = 8
read(3, "\202\0\0\0", 4)                = 4
read(3, "\0\0\0\vDCOPServer\0\0\0\0\17anonymous-658"..., 51) = 51
write(3, "\1\2\1\0\177\0\0\0\2\0\0\0", 12) = 12
write(3, "\0\0\0\17anonymous-6584\0\0\0\0\tktorrent\0"..., 67) = 67
write(3, "\0\0\0$/home/first/.kde/share/apps/"..., 60) = 60
read(3, "\2\5\0\2$\0\0\0", 8)           = 8
read(3, "\2\0\0\0", 4)                  = 4
read(3, "\0\0\0\tktorrent\0\0\0\0\17anonymous-6584\0"..., 36) = 36
read(3,  <unfinished ...>


The beginning always looks like this, and I don't know if all those ENOENT errors are normal or not:

Code: Select all
$ strace ktorrent
execve("/usr/bin/ktorrent", ["ktorrent"], [/* 34 vars */]) = 0
uname({sys="Linux", node="debian", ...}) = 0
brk(0)                                  = 0x80ac000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f20000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f1f000
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=144472, ...}) = 0
mmap2(NULL, 144472, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7efb000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/libktorrent.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200a\4"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1112116, ...}) = 0
mmap2(NULL, 1244224, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7dcb000
mmap2(0xb7ed4000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x109) = 0xb7ed4000
mmap2(0xb7edb000, 130112, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7edb000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/libgmp.so.3", O_RDONLY)  = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3000jJ"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=274864, ...}) = 0
mmap2(0x4a69b000, 272424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4a69b000
mmap2(0x4a6dd000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x42) = 0x4a6dd000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/libkparts.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3209\345"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=289084, ...}) = 0
mmap2(0x4ce32000, 289360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4ce32000
mmap2(0x4ce74000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x41) = 0x4ce74000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/libkio.so.4", O_RDONLY)  = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340K\247"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=3477912, ...}) = 0
mmap2(0x4e96e000, 3481396, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4e96e000
mmap2(0x4eca0000, 126976, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x332) = 0x4eca0000
mmap2(0x4ecbf000, 3892, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4ecbf000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/libkdeui.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\322yN"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=3102044, ...}) = 0
mmap2(0x4e675000, 3105084, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4e675000
mmap2(0x4e940000, 176128, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2ca) = 0x4e940000
mmap2(0x4e96b000, 316, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4e96b000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/libkdesu.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\375\337"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=88664, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dca000
mmap2(0x4cdfb000, 89016, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4cdfb000
mmap2(0x4ce10000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0x4ce10000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/libkwalletclient.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 0\342L"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=69488, ...}) = 0
mmap2(0x4ce1e000, 69840, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4ce1e000
mmap2(0x4ce2e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0x4ce2e000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/libkdecore.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\364"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=2354904, ...}) = 0
mmap2(0x4df96000, 2360576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4df96000
mmap2(0x4e1c4000, 69632, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22e) = 0x4e1c4000
mmap2(0x4e1d5000, 5376, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4e1d5000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/libDCOP.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`y\332L"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=203976, ...}) = 0
mmap2(0x4cd98000, 207712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4cd98000
mmap2(0x4cdc8000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x30) = 0x4cdc8000
mmap2(0x4cdc9000, 7008, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4cdc9000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)


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.
imported4-blujay
Registered Member
Posts
60
Karma
0

Thu Jan 18, 2007 7:15 am
I removed the RSS plugin from ~/.kde/share/apps/ktorrent/plugins but the problem still occurs.
imported4-blujay
Registered Member
Posts
60
Karma
0

Thu Jan 18, 2007 7:24 am
I've tried removing more torrents, but I've noticed that the last lines of the log file are always:

Code: Select all
Starting download
Loading 7 active chunk downloads
Loading chunk 109
Loading chunk 215
Loading chunk 255


The problem is, I don't know which torrent those chunks are in.
imported4-blujay
Registered Member
Posts
60
Karma
0

Thu Jan 18, 2007 7:34 am
(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:

Code: Select all
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1210444096 (LWP 9321)]
[KCrash handler]
#9  0xb7e12010 in std::fill<unsigned char*, int> ()
   from /usr/lib/libktorrent.so.0
#10 0xb7e07cec in bt::BitSet::BitSet () from /usr/lib/libktorrent.so.0
#11 0xb7e1ec39 in bt::ChunkDownload::load () from /usr/lib/libktorrent.so.0
#12 0xb7e448de in bt::Downloader::loadDownloads ()
   from /usr/lib/libktorrent.so.0
#13 0xb7e58aac in bt::TorrentControl::continueStart ()
   from /usr/lib/libktorrent.so.0
#14 0xb7e58dc8 in bt::TorrentControl::start () from /usr/lib/libktorrent.so.0
#15 0xb7e2d9a5 in bt::QueueManager::startSafely ()
   from /usr/lib/libktorrent.so.0
#16 0xb7e2e05a in bt::QueueManager::start () from /usr/lib/libktorrent.so.0
#17 0xb7e2e61c in bt::QueueManager::orderQueue ()
   from /usr/lib/libktorrent.so.0
#18 0x080892db in ?? ()
#19 0x0808e483 in ?? ()
#20 0x0808ebe4 in ?? ()
#21 0x4e10d14c in KUniqueApplication::processDelayed (this=0xbfb53ce0)
    at /home/ana/Debian/kdelibs/kdelibs-3.5.5a.dfsg.1/./kdecore/kuniqueapplication.cpp:444
#22 0x4e11c978 in KUniqueApplication::qt_invoke (this=0xbfb53ce0, _id=19,
    _o=0xbfb536c8) at ./kuniqueapplication.moc:86
#23 0x08060c6f in ?? ()
#24 0x4dabc2ef in QObject::activate_signal (this=0x8132060, clist=0x8131c80,
    o=0xbfb536c8) at kernel/qobject.cpp:2356
#25 0x4de4532b in QSignal::signal (this=0x8132060, t0=@0x8132088)
    at .moc/debug-shared-mt/moc_qsignal.cpp:100
#26 0x4dadbe72 in QSignal::activate (this=0x8132060) at kernel/qsignal.cpp:212
#27 0x4dae3844 in QSingleShotTimer::event (this=0x8132038)
    at kernel/qtimer.cpp:286
#28 0x4da541c6 in QApplication::internalNotify (this=0xbfb53ce0,
    receiver=0x8132038, e=0xbfb53a38) at kernel/qapplication.cpp:2635
#29 0x4da55fe3 in QApplication::notify (this=0xbfb53ce0, receiver=0x8132038,
    e=0xbfb53a38) at kernel/qapplication.cpp:2358
#30 0x4e155f8e in KApplication::notify (this=0xbfb53ce0, receiver=0x8132038,
    event=0xbfb53a38)
    at /home/ana/Debian/kdelibs/kdelibs-3.5.5a.dfsg.1/./kdecore/kapplication.cpp:550
#31 0x4d9e79c1 in QApplication::sendEvent (receiver=0x8132038,
    event=0xbfb53a38) at ../include/qapplication.h:520
#32 0x4da46bc3 in QEventLoop::activateTimers (this=0x80bce78)
    at kernel/qeventloop_unix.cpp:556
#33 0x4d9fbd0f in QEventLoop::processEvents (this=0x80bce78, flags=4)
    at kernel/qeventloop_x11.cpp:389
#34 0x4da6e719 in QEventLoop::enterLoop (this=0x80bce78)
    at kernel/qeventloop.cpp:198
#35 0x4da6e53a in QEventLoop::exec (this=0x80bce78)
    at kernel/qeventloop.cpp:145
#36 0x4da55d5f in QApplication::exec (this=0xbfb53ce0)
    at kernel/qapplication.cpp:2758
#37 0x08065d4b in ?? ()
#38 0x48cb4ea8 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#39 0x0805e2b1 in ?? ()
imported4-blujay
Registered Member
Posts
60
Karma
0

Thu Jan 18, 2007 8:08 am
That last backtrace was from 2.0.3. I recompiled SVN r621829 with full debugging symbols and here's its backtrace:

Code: Select all
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1211009344 (LWP 14493)]
[KCrash handler]
#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 ()
   from /usr/lib/libktorrent.so.0
#19 0x08087e9e in QColor::QColor ()
#20 0x08070d09 in bt::Error::toString ()
#21 0x08095b64 in QWidget::repaint ()
#22 0x4e10d14c in KUniqueApplication::processDelayed (this=0xbfebf7f0)
    at /home/ana/Debian/kdelibs/kdelibs-3.5.5a.dfsg.1/./kdecore/kuniqueapplication.cpp:444
#23 0x4e11c978 in KUniqueApplication::qt_invoke (this=0xbfebf7f0, _id=19,
    _o=0xbfebf1d8) at ./kuniqueapplication.moc:86
#24 0x08095705 in QWidget::repaint ()
#25 0x4dabc2ef in QObject::activate_signal (this=0x81ddd40, clist=0x81de110,
    o=0xbfebf1d8) at kernel/qobject.cpp:2356
#26 0x4de4532b in QSignal::signal (this=0x81ddd40, t0=@0x81ddd68)
    at .moc/debug-shared-mt/moc_qsignal.cpp:100
#27 0x4dadbe72 in QSignal::activate (this=0x81ddd40) at kernel/qsignal.cpp:212
#28 0x4dae3844 in QSingleShotTimer::event (this=0x81ddd18)
    at kernel/qtimer.cpp:286
#29 0x4da541c6 in QApplication::internalNotify (this=0xbfebf7f0,
    receiver=0x81ddd18, e=0xbfebf548) at kernel/qapplication.cpp:2635
#30 0x4da55fe3 in QApplication::notify (this=0xbfebf7f0, receiver=0x81ddd18,
    e=0xbfebf548) at kernel/qapplication.cpp:2358
#31 0x4e155f8e in KApplication::notify (this=0xbfebf7f0, receiver=0x81ddd18,
    event=0xbfebf548)
    at /home/ana/Debian/kdelibs/kdelibs-3.5.5a.dfsg.1/./kdecore/kapplication.cpp:550
#32 0x4d9e79c1 in QApplication::sendEvent (receiver=0x81ddd18,
    event=0xbfebf548) at ../include/qapplication.h:520
#33 0x4da46bc3 in QEventLoop::activateTimers (this=0x8165f48)
    at kernel/qeventloop_unix.cpp:556
#34 0x4d9fbd0f in QEventLoop::processEvents (this=0x8165f48, flags=4)
    at kernel/qeventloop_x11.cpp:389
#35 0x4da6e719 in QEventLoop::enterLoop (this=0x8165f48)
    at kernel/qeventloop.cpp:198
#36 0x4da6e53a in QEventLoop::exec (this=0x8165f48)
    at kernel/qeventloop.cpp:145
#37 0x4da55d5f in QApplication::exec (this=0xbfebf7f0)
    at kernel/qapplication.cpp:2758
#38 0x0806b225 in QString::~QString ()
#39 0x48cb4ea8 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#40 0x08066be1 in ?? ()
imported4-blujay
Registered Member
Posts
60
Karma
0

Thu Jan 18, 2007 8:41 am
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.
George
Moderator
Posts
5421
Karma
1

Thu Jan 18, 2007 5:42 pm
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.
imported4-blujay
Registered Member
Posts
60
Karma
0

Thu Jan 18, 2007 8:00 pm
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.
jdong
Registered Member
Posts
358
Karma
0

Thu Jan 18, 2007 10:08 pm
Did you install a ktorrent package from somewhere else before SVN compiling? It could be your distribution's ktorrent package installed a libktorrent to somewhere else.
George
Moderator
Posts
5421
Karma
1

Sat Jan 20, 2007 5:40 pm
Problems like this should be gone with the latest snapshot, the version number is now included in the name of the library.
imported4-blujay
Registered Member
Posts
60
Karma
0

Sun Jan 21, 2007 5:09 am
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.
imported4-blujay
Registered Member
Posts
60
Karma
0

Thu Feb 01, 2007 1:19 am
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.
jdong
Registered Member
Posts
358
Karma
0

Thu Feb 01, 2007 1:54 am
And how many connections were active at the time of the insane memory usage? Also, what filesystem is this with?
imported4-blujay
Registered Member
Posts
60
Karma
0

Thu Feb 01, 2007 2:45 am
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.
MoDaX
Registered Member
Posts
241
Karma
0
OS

I can confirm this bug

Tue Feb 06, 2007 7:56 am
blujay wrote: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'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/ ./


Bookmarks



Who is online

Registered users: Bing [Bot], Google [Bot], Yahoo [Bot]