memory leak caused by deluge gtk/ui

[flasher360]

the longer deluge gtk/ui runs the more memory it consumes. (i have 4gb ram here and after a few hours it uses about 60% of it)

deluged is working fine. no problems with it. (launched deluge in non-classic mode and quit the gtk/ui. this freed up the memory.)

system: ubuntu 10.10 64bit, core version: 1.3.1, libtorrent version: 0.15.4.0

(the problem existed in older core and libtorrent versions too. an update to the version above didn't help.)

more discussion in this thread: ​http://forum.deluge-torrent.org/viewtopic.php?f=7&t=33461

[mycosys]

Also happens on WinXP SP2 machine not running any server (windows gtk client 1.3.1 only, 1.3.1 server on ubuntu jaunty). 280M used after a couple of days, restart client and back down to 47M.

[foo]

Deluge / Deluge-gtk 1.3.1-2, last updated on the PPA

Memory shoots up to 90%+ cpu usage, and using tons of memory with 5 torrents active. I can close deluge and restart it and 10minutes later the same issues occur. Every 5-10 minutes, it randomly cause my ubuntu 10.10 maverick to freeze for a minute. This has been a problem for at least a month, since I started using deluge-gtk.

[foo]

also i have a similar system as op, Ubuntu 10.10, 64bit, with 4gb of mem. 3.2ghz dual core cpu and 7200rpm drives. Hope this gets fixed, ill be using qbitorrent until then.

Replying to foo:

Deluge / Deluge-gtk 1.3.1-2, last updated on the PPA

Memory shoots up to 90%+ cpu usage, and using tons of memory with 5 torrents active. I can close deluge and restart it and 10minutes later the same issues occur. Every 5-10 minutes, it randomly cause my ubuntu 10.10 maverick to freeze for a minute. This has been a problem for at least a month, since I started using deluge-gtk.

[Cas]

This needs retesting with the cpu patch for pygtk applied. It is fixed in Natty and shortly Maverick too: ​https://bugs.launchpad.net/ubuntu/+source/pygtk/+bug/664920

Personally I have not seen any issue with Deluge GTK and memory usage on Ubuntu so am a little surprised by this.

[kalpik]

deluged using up ALL memory here too! The situation seems to get worse when a tracker (with 40-50 torrents seeding) is down.

OS: Archlinux Deluge Version: 1.3.3 libtorrent version: 0.15.7

[kalpik]

Replying to kalpik:

deluged using up ALL memory here too! The situation seems to get worse when a tracker (with 40-50 torrents seeding) is down.

OS: Archlinux Deluge Version: 1.3.3 libtorrent version: 0.15.7

Oh, forgot to mention, in my case, the problem is deluged, and not the gtk-ui.. Exiting the UI (with daemon running) does not stop the memory from being used up!

[StaticmaN]

I have the same problem, Delugued begins to consume a lot of memory until the system perferomance break down.

I'm running Deluge 1.3.1-1ubuntu2 Daemon and WEB-UI interface in Ubuntu 11.04 64b.

The "top" linux command shows near 7,5Gb (the system have 8Gb) of memory used but Deluged process have 0,6% of memory. If I turn off Deluge, this behaviour doesn't reproduce.

[igor.katson]

Same stuff with deluged consuming lots of memory. Restarting the UI does not help. I have around 240 torrents seeded, and right after starting deluge consumes around 50-100 megabytes. Some time later around a gigabyte.

Client Version: 1.3.3 Server Version: 1.3.3 Libtorrent Version: 0.15.7.0

OS: Archlinux

[serious Sam]

got the same problem probably using windows running latest stable release 1.3.1

Core Version: 1.3.1 libtorrent version: 0.14.12.0

here is screen a screen showing the problem

[effede]

Got this problem on a new machine with fresh Windows XP SP3 install and Deluge 1.3.5. I can confirm that it is a problem with the UI only. On my system the memory used by Deluge grows rapidly up to 1.9 GB (there 2 GB of RAM) and when the RAM saturates, the crash occurs. The more I "play" with the UI, the more rapidly the memory grows.

The first visible message is :

Visual C++ Runtime Error!

Program C:\Deluge\deluge.exe

Thist application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.

And in the debug console :

C:\Program Files\Deluge\library.zip\twisted\internet\gtk2reactor.py:327: GtkWarning: gdkgc-win32.c:830: SaveDC failed: Espace insuffisant pour traiter cette commande.
C:\Program Files\Deluge\library.zip\twisted\internet\gtk2reactor.py:327: GtkWarning: gdkgc-win32.c:970: RestoreDC failed: Paramètre incorrect.
C:\Program Files\Deluge\library.zip\twisted\internet\gtk2reactor.py:327: GtkWarning: gdkpixmap-win32.c:279: CreateDIBSection failed: Paramètre incorrect.
**
Gdk:ERROR:gdkdrawable-win32.c:2040:_gdk_win32_drawable_finish: assertion failed: (impl->hdc_count == 0)

The messages are always exactly the same.

What is strange is that this installation is the same (OS, version, configuration...) I use with Deluge since 2 years and this is the first time I encounter this problem...

I tried with 1.3.3 with the same result. All of the GTK+ DLLs are also of the newest version.

[effede]

The problem is GONE ! nearly...

I was using Deluge only from Windows RDP (as I always did even before I knew this problem), and since I stopped recently, the problem did not occured a single time.

So, normal access to the computer : everything is OK. RDP : the problem arise everytime.

[Cas]

Just to follow up that there are ​bugzilla reports for gtk memory leaks in windows and it looks as though the major issues are fixed in gtk 2.24.14 but we cannot package this until a windows gtk/pygtk build is available.

[Cas]

Just to reiterate the only workaround is to not leave the Gtk UI running for extended periods which can be achieved by using Deluge in thinclient mode so the daemon runs in the background and you connect with the Gtk client, therefore crashes therefore won't affect torrents.

I have noticed ​tschoonj has packaged a 64-bit version of GTK2 so it might be possible to produce a test build to see if that fixes the issues as it's the latest GTK2 version: 2.24.30.

[Alexey104]

I am sorry for resurrecting such an old ticket, but just for the info:
I still have this issue in ArchLinux? with Deluge 2.0.4(dev56). Deluged daemon memory usage is OK, but gtk-ui grows up in memory consumption slowly, but endlessly, until OOM if opened for a long time, and swap usage is 100%. And this is not in Windows.

[fiskmaas]

Replying to Alexey104:

I am sorry for resurrecting such an old ticket, but just for the info:
I still have this issue in ArchLinux? with Deluge 2.0.4(dev56). Deluged daemon memory usage is OK, but gtk-ui keeps growing in memory consumption slowly, but endlessly, until OOM if opened for a long time, and swap usage is 100%. And this is not in Windows.

I am having same issue in Manjaro. Deluge-gtk eating up the memory slowly over time while the daemon is working fine. Restarting helps.

[Cas]

@fiskmass How many torrents do you roughly have? And over what period of time do you see the increase in memory consumption?

[starslab]

Replying to Cas:

@fiskmass How many torrents do you roughly have? And over what period of time do you see the increase in memory consumption?

I'm seeing this issue as well, or something very like it on Ubuntu 22.04 with 8GB RAM. Something slowly grows and eats all the memory, then all the swap, and eventually the VM locks up. Closing/restarting Deluge before the system is too far gone seems to reset the issue. Running about 30 torrents, issue takes a couple days (Less than a week I'm pretty sure) to go from fresh boot to locked up VM with thrashing disk)

Deluge installed via Deluge-PPA

Deluge 2.1.0

libtorrent 2.0.5.0

[Alexey104]

A workaround(but not a fix) is to run Deluge in thin client mode, keep deluged daemon running at the background and only open gtk-ui when you actually need it keeping it closed the rest of the time.

[starslab]

Replying to Alexey104:

A workaround(but not a fix) is to run Deluge in thin client mode, keep deluged daemon running at the background and only open gtk-ui when you actually need it keeping it closed the rest of the time.

I can confirm that this does work for me.