Bug 148385 - massive memory usage in ktorrent
Summary: massive memory usage in ktorrent
Status: RESOLVED FIXED
Alias: None
Product: ktorrent
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Joris Guisson
URL:
Keywords:
: 172437 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-07-31 08:54 UTC by Boyd Stephen Smith Jr.
Modified: 2010-11-21 09:50 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Boyd Stephen Smith Jr. 2007-07-31 08:54:52 UTC
Version:           2.2.1 (using KDE 3.5.7, Gentoo)
Compiler:          Target: x86_64-pc-linux-gnu
OS:                Linux (x86_64) release 2.6.20-gentoo-r8

Example line from top:
822259 bss       15   0 3621m 2.6g  21m S    6 69.2  37:00.31 ktorrent

That 3.6Gigs of virtual memory.  1Gig swap + 2.6Gig RAM.
97 torrents listed, 58 running, 57 seeding, 11 actively seeding, 1 downloading.

This seems a bit large.  It's also seems to be a memory leak, as usage increases over time.  Yesterday was over 7Gig virtual memory.
Comment 1 Boyd Stephen Smith Jr. 2007-07-31 08:56:07 UTC
Plugins Loaded:
Bandwidth Scheduler
IP Filter
Import
Info Widget
RSS Feeds
Search
Comment 2 Boyd Stephen Smith Jr. 2007-07-31 08:59:04 UTC
Unloading all plugins does not reduce memory consumption, but I'm not sure if it will prevent the consumption initially.
Comment 3 Joris Guisson 2007-08-15 11:44:14 UTC
Does the memory usage drop back if you stop all torrents ?
Comment 4 Boyd Stephen Smith Jr. 2007-08-15 21:13:48 UTC
On Wednesday 15 August 2007, Joris Guisson <joris.guisson@gmail.com> wrote 
about '[Bug 148385] massive memory usage in ktorrent':
> Does the memory usage drop back if you stop all torrents ?


IIRC, No.  Otherwise, I'd do that rather than quitting and restarting 
KTorrent.

I'll reconfirm that though next time the memory spikes (should be later 
today).
Comment 5 Boyd Stephen Smith Jr. 2007-08-17 09:45:45 UTC
> Does the memory usage drop back if you stop all torrents ?


Correcting my earlier statements, yes.  The memory usage does drop back to 
acceptable levels if you Stop All and Start All.
Comment 6 Boyd Stephen Smith Jr. 2007-08-18 18:11:43 UTC
On Friday 17 August 2007, Boyd Stephen Smith Jr. <bss03@volumehost.net> 
wrote about '[Bug 148385] massive memory usage in ktorrent':
> > Does the memory usage drop back if you stop all torrents ?
>
> Correcting my earlier statements, yes.  The memory usage does drop back
> to acceptable levels if you Stop All and Start All.


Grr, just tried this again this morning and it did *not* reduce the memory 
usage, while stopping the application freed over 1.5G of memory.

I'm still running a number of plug-ins, so I'm not entirely sure where the 
memory leak is.  I'm willing to test disabling virtually any plug-in 
exception the RSS feeds -- any likely candidates?
Comment 7 Boyd Stephen Smith Jr. 2007-08-25 17:39:56 UTC
On Wednesday 15 August 2007, Joris Guisson <joris.guisson@gmail.com> wrote 
about '[Bug 148385] massive memory usage in ktorrent':
> Does the memory usage drop back if you stop all torrents ?


Today, from htop, after stopping all torrents:
  PID USER     PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
204951 bss       15   0 2669M 2083M 17652 S 31.1 53.5 35:41.63 
ktorrent -icon kt
Comment 8 Tim Hutt 2007-09-20 21:30:35 UTC
I had a possibly related thing. I left ktorrent running with one torrent stopped (not enough space for it) and the scheduler on. When I came back the next day it had used up all 512MB of RAM, and 100% CPU, just doing nothing! I killed it, and when I ran it again the torrent was still stopped.

Weird. Definitely some memleaks in there (ktorrent 2.2.1).
Comment 9 Joris Guisson 2008-08-01 12:51:42 UTC
SVN commit 840601 by guisson:

Merged fix from trunk which fixes some weird behavior in the chunkmanager potentially causing a lot memory usage

BUG: 148385


 M  +1 -0      ChangeLog  
 M  +7 -5      libbtcore/diskio/chunkmanager.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=840601
Comment 10 Joris Guisson 2008-10-09 12:39:50 UTC
*** Bug 172437 has been marked as a duplicate of this bug. ***
Comment 11 Joris Guisson 2010-11-21 09:50:46 UTC
commit 2d2498280f3c2541815376ea9695e3f82f534c29
branch refs/tags/v3.1.2
Author: Joris Guisson <joris.guisson@gmail.com>
Date:   Fri Aug 1 10:51:15 2008 +0000

    Merged fix from trunk which fixes some weird behavior in the chunkmanager potentially causing a lot memory usage
    
    BUG: 148385
    
    svn path=/branches/ktorrent/3.1/; revision=840601

diff --git a/ChangeLog b/ChangeLog
index 6a440cf..e6f4434 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -5,6 +5,7 @@ Changes in 3.1.2 :
 - Backported some improvements to download thread 
 - Make sure cookies are not sent in http announces
 - Fix crash at startup which started happening since KDE 4.1
+- Fix problem causing massive memory usage (148385)
 
 Changes in 3.1.1 :
 - Fix wrong icon name in PeerView for encrypted peers 
diff --git a/libbtcore/diskio/chunkmanager.cpp b/libbtcore/diskio/chunkmanager.cpp
index e9fb84f..f8e3eae 100644
--- a/libbtcore/diskio/chunkmanager.cpp
+++ b/libbtcore/diskio/chunkmanager.cpp
@@ -310,7 +310,7 @@ namespace bt
 		{
 			// load the chunk if it is on disk
 			cache->load(c);
-			loaded.insert(i,bt::GetCurrentTime());
+			loaded[i] = bt::GetCurrentTime();
 			bool check_allowed = do_data_check && (max_chunk_size_for_data_check == 0 || tor.getChunkSize() <= max_chunk_size_for_data_check);
 			
 			// when no corruptions have been found, only check once every 5 chunks
@@ -339,8 +339,12 @@ namespace bt
 				recheck_counter++;
 			}
 		}
+		else
+		{
+			// update timestamp 
+			loaded[i] = bt::GetCurrentTime();
+		}
 		
-		loaded.insert(i,bt::GetCurrentTime());
 		return c;
 	}
 		
@@ -390,9 +394,7 @@ namespace bt
 					cache->save(c);
 				c->clear();
 				c->setStatus(Chunk::ON_DISK);
-				QMap<Uint32,TimeStamp>::iterator j = i;
-				i++;
-				loaded.erase(j);
+				i = loaded.erase(i);
 				num_removed++;
 			}
 			else