memory leaks in indicator-multiload

[Scott Moser]

Hi,
  I'm using the ppa build from ppa:indicator-multiload/stable-daily .
  It seems there is a fairly substantial memory leak.
  On start up, top shows something like 8k memory resident. Upon returning from the past weekend that number was ~ 500M.

  A short ~ 1 minute run under valgrind shows ends with:

==6082== LEAK SUMMARY:
==6082== definitely lost: 23,814 bytes in 941 blocks
==6082== indirectly lost: 240 bytes in 10 blocks
==6082== possibly lost: 275,452 bytes in 2,018 blocks
==6082== still reachable: 588,251 bytes in 5,070 blocks
==6082== suppressed: 0 bytes in 0 blocks
==6082== Reachable blocks (those to which a pointer was found) are not shown.
==6082== To see them, rerun with: --leak-check=full --show-reachable=yes
==6082==
==6082== For counts of detected and suppressed errors, rerun with: -v
==6082== ERROR SUMMARY: 595 errors from 595 contexts (suppressed: 8 from 6)

I'll attach the full valgrind log .

I'm guessing its not as simple as it seems, and that the info isn't terribly helpful, but I'm definitely seeing memory leaks in this version.

[Michael Hofmann (mh21)]

If it is a memory leak, it should grow over time. Could you check whether the valgrind log of a longer run reports a higher memory use for you?

[Robert Lange (rcl24)]

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.

[Robert Lange (rcl24)]

Blast! The attachment for the 50msec interval should be labeled 1 minute, not 2.

[Michael Hofmann (mh21)]

Thanks, I will take a look at it...

[Michael Hofmann (mh21)]

This is a bug in libdbus-menu, and has already been fixed, but not backported to natty. I'm marking this as a duplicate, but you might want to ask for a backport of the fix from the libdbus-menu people.

I could also provide one in the ppa (it's a one-line change), but last time people were complaining heavily about my fixed unity packages there. Tell me what you think :-).

[Michael Hofmann (mh21)]

A fixed version of libdbus-menu should now be available in natty.