Comment 3 for bug 796627

I can confirm that there is a memory leak. Using the latest natty updates, I ran it for 5 days with 500msec interval and recorded a memory use for indicator-multiload of about 290MB.

Using 500msec interval and valgrind with max num-callers for 1 minute, I got 17,518 bytes definitely lost with 17,214 bytes definitely lost from multiloadindicator.c line 891.

Using 50msec interval and valgrind with max num-callers for 1 minute, I got 170,417 bytes definitely lost with 170,113 bytes definitely lost from multiloadindicator.c line 891.

To demonstrate that the leak continues over time, using 500msec interval and valgrind with max num-callers for (slightly more than) 2 minutes, I got 37,549 bytes definitely lost with 37,245 bytes definitely lost from multiloadindicator.c line 891.

Clearly, the number of bytes lost scales linearly both with the interval setting and with the running time.

multiloadindicator.c line 891 corresponds to multiloadindicator.vala line 80.

Due to a lack of source code comments in multiloadindicator.vala, I do not really know what that code is supposed to do. However, if I were to venture a guess, I would say that it rewrites the indicator menu labels with new load information at each interval tick. I would guess the leak is caused by the old char* label for the menu item being discarded without being freed. Whether this is a bug in indicator-multiload code, vala C code generation, or gtk code, I don't know these libraries well enough to say.

The valgrind files show some other small leaks, but clearly this one is the big bleeder.