Memory leak - The memory is taking more and more space until the computer becomes deadly slow.

Same issue, same Kernel, same distro. Suddenly eats 1.5 Gb of memory making my system really slow.

In the memory map of the System Monitor, I can see that :

 - /usr/lib/libQtGUI.so.4.7.0 takes 5.3 MB
 - /usr/lib/libtorrent-rasterbar.so.6.0.0 takes 2.4 MB
 - /usr/lib/libQtCore.so.4.7.0 takes 1.5MB
 - /usr/bin/qbittorrent takes 1.5 MB

When my qbittorrent takes 14.5 MB

I see that Ubuntu also updated libtorrent to v0.15.x (Used to be libtorrent v0.14.x).
I'm not sure that the issue actually comes from qBittorrent but I will make some tests.

Also note that Ubuntu 10.10 is using an unstable version of Qt 4.7.

I'm personally using qBittorrent 2.4.0 on Ubuntu v10.04 and I do not notice any issue.

This issue affects me, too. I'm using Gentoo Linux, qBittorent 2.4.0, libtorrent 0.15.3.

qBittorent right now has a Resident Set of 1.4g and a CPU usage of 100%. When I try to close it, the window disappears but the process keeps running.

pmap shows nearly all of the used memory as Anonymous, so I don't think this is a problem with Qt.

I tried to reproduce yesterday (with Ubuntu maverick and qBittorrent v2.4.0) but it seemed to work fine. How long does it take to eat so much memory?

Also, Qt has been updated to 4.7 stable very recently on Maverick. Please make sure this does not solve the issue.

Same in Arch. Qt version 4.6.3.

antarhes > Is Arch using libtorrent v0.15.3 also?

Yes, 0.15.3

I talked about this with the libtorrent author yesterday and he told me that it might be caused by invalid tracker URLs. He said that there are still some tracker announcing issues in v0.15.3 that he is hoping to fix for v0.15.4.

An easy way to test it he said would be to create a torrent with an invalid tracker URL (for example not starting by http://) and load it.

How easy is it to reproduce?

It would be interesting to see the output of strace when cpu usage gets abnormally high. The libtorrent bug report seems to suggest an issue with device poll() implementation in asio. It would be interesting to see if it is the same issue here.

If it is, then an easy fix would be to recompile libtorrent with -DBOOST_ASIO_DISABLE_DEV_POLL

Here is a part of strace output.

antarhes > Good, this is the same poll() issue as in the libtorrent bug tracker.
How hard would it be for you to recompile libtorrent with -DBOOST_ASIO_DISABLE_DEV_POLL flag?

Easy, just wait)

Are any of you saving to a network directory by any chance (e.g. NFS)?

Build successfully, but i can test new version only tomorrow.
>> Are any of you saving to a network directory by any chance (e.g. NFS)
I don't.

I'm also experiencing the memory leak. It takes about 30-40mins to use up 700MB of RES memory. At that point the computer becomes completely unresponsive. I think the problem is neither Qt 4.7 or libtorrent because pmap shows that the memory that is leaking is anonymous.

a2a00000 0 2004 2004 rw--- [ anon ]
7b800000 0 2024 2024 rw--- [ anon ]
7b600000 0 2036 2036 rw--- [ anon ]
7ba00000 0 2036 2036 rw--- [ anon ]
7ac00000 0 2048 2048 rw--- [ anon ]
088c0000 0 3636 3584 rw--- [ anon ]
08f4c000 0 191316 190812 rw--- [ anon ]

Rebuild libtorrent with flag -DBOOST_ASIO_DISABLE_DEV_POLL not solved problem. May be memory leak begins when qbittorrent starts to check downloaded file.

Ok. Thanks.

Message from libtorrent author:
***
could somebody that experience this run a heap profile? google-performance tools are good for this for instance.

You can inject tcmalloc when starting qBittorrent or Deluge, specify to enable heap profiling and go. Generate a report with pprof and one of the heap files from when libtorrent started using a ton of memory and attach it here.

See: http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html
***

Here is pprof report for second .heap file.

Thanks a lot antarhes! I hope this will help the libtorrent author fix the issue.

I had a look at your output and it seems like it may be related to tracker connections (as initially suspected by libtorrent author).

To Ubuntu Maverick users > the libtorrent author asked me to package the latest SVN so that you are able to test if it fixes your issue (if it does, he will release v0.15.4 very soon).

Please test my PPA by typing:
sudo add-apt-repository ppa:hydr0g3n/ppa
sudo apt-get update && sudo apt-get dist-upgrade

This should update both libtorrent-rasterbar and qbittorrent.

Note that I have just uploaded the sources to my PPA and it may take up to a few hours to build.

antarhes > The libtorrent author said that it might be more helpful to get the output of:
pprof --ps [program] [heap] >profile.ps

FYI: Your libtorrent-rasterbar build failed due to differences between the svn tree and a release tarball. There need to be some changes with the docs for it to build in a debian/ubuntu chroot. The attached patch should get it to build.

Just a heads up on the Ubuntu release schedule, noon UTC on October 6 is pretty much the last chance to get anything but release critical fixes in.

Thanks for looking into this!

SVN snapshot that should fix the issue. I will try to upload DEB packages now.

Could anyone using Ubuntu maverick please try these two packages and confirm that it fixes the issue?

Any chance of a x86_64 libtorrent deb?

So far the updated deb packages work OK on my system (I did a clean install yesterday with RC maveric).
Last week I did an update from lynx to beta, but I was unhappy with the results (and qbittorrent crashing was also a mayor issue for me, so I was considering going back to lynx)...

I tested for 2 hours (and I downloaded 3GB of data) these packages above attached by Christophe Dumez the memory leak is gone.
Please go ahead and upload into the archive.

Did you have a download finish?

For me the problem is 100% reproducible starting after the download
finishes and seeding begins (in deluge).

On Mon, Oct 4, 2010 at 7:50 AM, Alessandro Ghersi <email address hidden> wrote:
> I tested for 2 hours (and I downloaded 3GB of data) these packages above attached by Christophe Dumez  the memory leak is gone.
> Please go ahead and upload into the archive.
>
> ** Attachment added: "qbittorrent.png"
>   https://bugs.launchpad.net/ubuntu/+source/qbittorrent/+bug/639659/+attachment/1670541/+files/qbittorrent.png
>
> --
> Memory leak - The memory is taking more and more space until the computer becomes deadly slow.
> https://bugs.launchpad.net/bugs/639659
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (653627).
>
> Status in Deluge BitTorrent Client: New
> Status in Bittorrent library by Rasterbar software: Unknown
> Status in qBittorrent - An advanced bittorrent client in C++ / Qt4: New
> Status in “libtorrent-rasterbar” package in Ubuntu: Triaged
> Status in “qbittorrent” package in Ubuntu: New
>
> Bug description:
> Binary package hint: qbittorrent
>
> I guess it is related to some packet memory allocation that are not delete when they are committed to the hard drive. The bug happend even if there is only one file to download.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 10.10
> Package: qbittorrent 2.4.0-0ubuntu1
> ProcVersionSignature: Ubuntu 2.6.35-21.31-generic 2.6.35.4
> Uname: Linux 2.6.35-21-generic i686
> NonfreeKernelModules: nvidia
> Architecture: i386
> Date: Wed Sep 15 17:13:26 2010
> ProcEnviron:
>  LANG=fr_FR.UTF-8
>  SHELL=/bin/bash
> SourcePackage: qbittorrent
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/deluge/+bug/639659/+subscribe
>

Yes I have the downloads finished and seeding. Maybe deluge needs a rebuild against libtorrent svn snapshot

libtorrent-rasterbar v0.15.4 was just released. Is there still time to upload it?

On Tue, Oct 5, 2010 at 11:50 AM, Christophe Dumez <email address hidden> wrote:
> libtorrent-rasterbar v0.15.4 was just released. Is there still time to
> upload it?

I should be able to just get it in. Thanks for all your work on this!

This bug was fixed in the package libtorrent-rasterbar - 0.15.4-0ubuntu1

---------------
libtorrent-rasterbar (0.15.4-0ubuntu1) maverick; urgency=low

  * New upstream bug fix release.
   - Fixed tracker announce issue which could cause high
     CPU and memory usage. (LP: #639659)
   - Fix issue which can cuase an infinite loop and result
     in Deluge lockingup. (LP: #654906)
   - Many thanks to Christophe Dumez, upstream author
     Arvid Norberg, and Daniel Hollocher for making
     sure these fixes landed in Maverick.
 -- Andrew Starr-Bochicchio <email address hidden> Tue, 05 Oct 2010 12:01:20 -0400

The problem is fixed :) Thank you :)

No problem Natim. Do not forget to use my Ubuntu PPA to get the latest fixes.

I have libtorrent-rasterbar6 ver 0.15.4-0ubuntu1 but am still getting this problem of 100% CPU usage by deluge. I have deluge ver 1.3.0-0ubuntu1.1

Do I need to do something else to activate the fix?

In v0.15.4, There is still a high CPU usage problem which occurs just before torrent completion. It has been fixed in libtorrent SVN and will be included in the soon-to-be released v0.15.5. Maybe the Deluge guys should package a SVN snapshot of the RC_0_15 branch on their PPA (as I do for the qBittorrent PPA).

I am able to reproduce the problem every time when I open completed files from Files tab, after that CPU jumps to 100%

@danizmax: Your problem seems unrelated, please file a separate bug report against qBittorrent.

Nice to know this. Just putting my 2 paise to remember to try your PPA . I'm on Debian Squeeze.

I still have a memory leak with qbittorrent 2.6.6 under windows seven x64

It seems that some memory from files are not realeased beacause when I see the ram usage (with rammap), Files from my torrents are using ~1GB each or more.
And it's doing this under seeding. I didn't see it during a download. But I can try a bigger one.

And maybe it is related, or not, but when checking files qbittorent is using all the ram (4GB for me) instead of just a few hundred of MB (as vuze). In that case, the computer is dead for a while...

ps : sorry for my poor english :D

The memory bug is still present in qBittorrent v2.7.3 (for windows) on Windows 7 x64. The download and upload speed are very good (ex: D: 10.6 - 11.2 MiB/s -- U: 2 - 3.6 MiB/s), but when downloading, seeding (after a file just finished downloading) or checking files, it uses all the physical memory, the CPU jumps on 85-95% and the the computer becomes nearly unresponsive. If a file which has just finished downloading (and qB is seeding it) is paused, the memory and the CPU comes back to normal. If the paused file is started (for sedding), the memory and the CPU remain at their normal values, but the upload speed is slow. Tested on files with sizes from 100M up to 10G.

I can confirm the info in the above post that John Doe wrote on 2011-04-18.

I also have this problem.

There's a handy utility called RAMMap for Windows that explains what's going on: http://download.cnet.com/RAMMap/3000-2094_4-75186110.html

Active torrent files get cached into the "active" part of RAM that clogs up the system as it can't be overwritten by other programs demanding memory. This also happens with Deluge. They should instead be cached into "standby" memory that yields itself when a higher priority program like a browser or game needs that memory. This is how uTorrent operates.

As it is now, cached torrent files slowly eat up RAM until 3,7 GB of my 4 GB used and the PC comes to a crawl.

The solution to the memory leak problem that Sander (s4nder86), John Doe (cs1-6pics), and youen (youri-56-gmail) describe happening on windows can be solved by qbittorrent managing the cache and disabling the windows cache.

Windows cache does not do a good job of releasing the memory used for caching torrent data. The faster you are uploading or downloading, the more likely you are to see this problem. This used to be a problem for utorrent as well back when Windows Vista first came out. After many bug reports and arguing with users, they solved it by changing the default of utorrent to disabling the windows cache and having utorrent manage the caching of reads and writes.

I have attached a pic to show the default cache management settings of utorrent. qbittorrent needs to manage the caching of data to solve this phantom memory leak. I call it phantom because qbittorrent itself won't show in task manager as using the memory, but once you close/shutdown qbittorrent you get all the memory back.

http://imageshack.us/photo/my-images/690/cachesettings.jpg/

For windows users I think I've solved it. See my comment on this bug https://bugs.launchpad.net/qbittorrent/+bug/841138/comments/11