FAHControl (Windows) memory leak ... grows to fill virtual memory

[bb30994]

(I though this had been reported but I can't find it. It's still true in 7.4.16)

[jcoffland]

I don't know. Was there a forum post to go with this?

[bb30994]

07:57 AM 69.6
02:00 PM 116.0
03:06 PM 134.6
11:17 PM 268.6
10:33 AM 452.5
12:33 PM 484.6

https://foldingforum.org/viewtopic.php?f=96&t=29242&p=289414#p289414
https://foldingforum.org/viewtopic.php?f=104&t=29601
https://foldingforum.org/viewtopic.php?f=104&t=29899&p=294710#p294701
https://foldingforum.org/viewtopic.php?f=96&t=29921&p=289172#p289172
https://foldingforum.org/viewtopic.php?f=96&t=29242&p=289414#p289414
(and others)

[informatorius]

@jcoffland :
Looks like python has a garbage collector. So maybe it is not a memory leak but the gc just decides to not release the memory yet and a gc.collect() could help to enforce it? Or it can at least show which objects cannot be collected. Edit: Tried gc.collect() and it did not help.

If this is a gtk issue then gtksharp or other newer gtk version could be a workaround.
I currently try to build FahControl for Windows using different gtk+ versions to see if mem leakage changes. Edit: gtksharp or Glade Gtk+2 seem to help much. It has Gtk+ 2.24.23 which is newer than last gnome windows binaries 2.24.10. There the mem leak seems fixed.

Which version of gkt+ where you using to build Windows FahControl?

[informatorius]

This is how I build FahControl using Glade Gtk+ 2.24.23 on Windows 7 with Python 2.7:

1. Download GladeGtk+2 3.8.5: http://ftp.gnome.org/pub/GNOME/binaries/win32/glade/3.8/
2. unzip to C:\GladeGtk+2
3. open cmd shell
4. set path=C:\GladeGtk+2\bin;%path%
5. cd to folder fah-control
6. python setup.py install
7. gui\FAHControl.exe
   => nearly no mem leak

[jcoffland]

Awesome. That's what I thought was wrong. I'll build with the newer gtk. Thanks for figuring this out!

[informatorius]

Mem usage on Windows 7 64bit after 12 hours (running 2 GPU slots):

FahControl build with Glade Gtk+
initial mem: 20.740 KB
after 12 hours: 22.776 KB
=> mem leak = 122 KB per month

FAHClient 7.4.16 beta
initial mem: 13.320 KB
after 12 hours: 34.640 KB
=> mem leak = 1279 KB per month

So both leaks seem acceptable.

[jcoffland]

@informatorius, I installed GladeGtk+2 3.8.5 as you suggested above. Unfortunately, it had no effect on the FAHControl build. You mention pygtk 2.24.23. Where did you find this version?

[jcoffland]

I think we are getting hit by this bug: https://bugzilla.gnome.org/show_bug.cgi?id=685959. More info here: https://stackoverflow.com/questions/16366845/working-around-a-big-memory-leak-in-gtk-when-redrawing-a-label

[informatorius]

Inside the C:\Program Files (x86)\Glade Gtk+2\bin folder there is the libgtk-win32-2.0-0.dll 2.24.23 and all other dlls. I see in my checklist step 6) I made a mistake. It needs to be "python setup.py install" to get the dlls copied to the fah-control folder.

"python setup.py install" then should look like this:
[...]
copying c:\Program Files (x86)\Glade Gtk+2\bin\libatk-1.0-0.dll -> gui\lib\libatk-1.0-0.dll
[...]

As I understand it is not a build issue in PyGtk but a runtime issue of gtk+ 2.24.10 for Windows. This is why it needs to be replaced by a newer version like the one provided with Glade or a custom gtk+ build like used in your referenced stackoverflow issue. (PyGTK does not change and stays at latest api version 2.24.0)

---

Latest of gtk+ is 2.24.32 and I could build it from source using Windows msys2. https://www.gtk.org/download/windows.php
All you need to change from the tutorial is to replace the lines

pacman -S mingw-w64-x86_64-gtk3
pacman -S mingw-w64-x86_64-python2-gobject

with the 32bit version and gtk2

pacman -S mingw-w64-i686-gtk2
pacman -S mingw-w64-i686-python2-gobject

[jcoffland]

Ok, I've got the build working. Client beta forthcoming. Thanks!

[informatorius]

It is solved.