OmegaPhil/hardware-monitor-applet

Massive memory leak

Closed this issue · 8 comments

495MB RSS on an applet, thats ridiculous. Is the value history list ever cleared out?

I've read the valgrind manual, and am currently running this under valgrind memcheck for 1-2 days to see what leaks are happening. If this isn't enough, I need to follow it up with massif.

xfce4 hardware monitor applet - massif visualiser memory leak - 21 01 14

massif shows that the memory leak is not in my code but something to do with the C gtk main loop, and libgnomecanvas repeatedly calling gdk_region_new. No idea why yet, or how to fight it.

Grasping at straws here - testing running Gnome::Canvas::init() in a special panel init function rather than the construction function.

This has made no difference. I'm now running the GNOME 2 Hardware Monitor applet to see if this has the same memory leak

It does!! Running it in Debian oldstable, RSS at 75976KB after about a day...

I have looked into libgnomecanvas from libgnomecanvas2-dev, and there appears to be a suspicious allocation of a GdkRegion that isn't used in libgnomecanvas/gnome-canvas.c:paint (line 3114) - I have commented that out and am testing on my main machine. This is the only gdk_region_new call which would fit nicely with my earlier findings.

Why doesn't GNOME have a source repo availalble for this code so I can check why the lines are there?

This finally works! While RSS did grow slightly over a few days, it actually went down today!

Reported upstream: https://bugzilla.gnome.org/show_bug.cgi?id=729717

libgnomecanvas is under the 'unmaintained/deprecated' section so this will probably be ignored.