Possible memory leak

[Wilhelm Schuster]

After some runtime (ca. 1 week), the memory usage of indicator-multiload rises up really high (>800MB).
My System: Ubuntu 12.10 64bit
I'm using version 0.3 from the Ubuntu stable ppa (https://launchpad.net/~indicator-multiload/+archive/stable-daily), but i had the same problem with the package from the main Ubuntu repositories (version 0.2).

[Michael Hofmann (mh21)]

Hi Wilhelm,

the problem is I don't see this myself while using the same version of Ubuntu and the indicator.

If you have some time we can try to debug this.

First it would be interesting how fast the memory leak grows. If you enter the following command into a terminal, it will output the memory use every 60s:
  while sleep 60; do ps uh -p `pgrep -f indicator-multiload`; done

The memory use (virtual memory size) can be found in the 5th column. Could you post the output of the command above from a newly started session here?

[Michael Hofmann (mh21)]

Hmm, now that I take a look at it, I see the memory usage increasing by about 50bytes/second, but this would only be 36MB/week.

[Wilhelm Schuster (wilhelm-schuster-95-n)]

One thing I forgot to mention is, that I'm running on a dual display setup, so indicator-multiload is beeing displayed twice.

[Michael Hofmann (mh21)]

Just for the record, I found sth (about 3MB/h with very high update rate), but don't know what to make of it.

Seems like the lost memory is allocated in invoke_get_all_properties_in_idle_cb, but I have no idea where it is supposed to get freed.

An example:
 538,656 bytes in 1,086 blocks are possibly lost in loss record 5,842 of 5,842
    at 0x4C29CD5: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x4C29D2E: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x643F5E7: slab_allocator_alloc_chunk (gslice.c:1381)
    by 0x6487CCB: g_slice_alloc (gslice.c:724)
    by 0x64A15C2: g_variant_new_from_children (gvariant-core.c:476)
    by 0x649EB50: g_variant_builder_end (gvariant.c:3580)
    by 0x64A0362: g_variant_valist_new (gvariant.c:4548)
    by 0x64A06C6: g_variant_new_va (gvariant.c:4702)
    by 0x64A0BCF: g_variant_builder_add (gvariant.c:4854)
    by 0x5D3513C: g_dbus_message_to_blob (gdbusmessage.c:2313)
    by 0x5D2A432: g_dbus_connection_send_message_unlocked (gdbusconnection.c:1650)
    by 0x5D2CFCF: g_dbus_connection_send_message (gdbusconnection.c:1764)
    by 0x5D2DBBE: invoke_get_all_properties_in_idle_cb (gdbusconnection.c:4426)
    by 0x646CAB4: g_main_context_dispatch (gmain.c:2715)
    by 0x646CDE7: g_main_context_iterate.isra.24 (gmain.c:3290)
    by 0x646CEA3: g_main_context_iteration (gmain.c:3351)
    by 0x5D0A74B: g_application_run (gapplication.c:1624)
    by 0x415A84: main_main (main.c:1692)
    by 0x695A76C: (below main) (libc-start.c:226)

[Wilhelm Schuster (wilhelm-schuster-95-n)]

It seems that the bug appears after approx. 4.5 to 5 days of runtime. Before that time there was just a little growth (from 4MB to 12MB). I've attached a part of the log file where you can see the growing memory usage. Also the problem stays the same if you restart indicator-multiload.

[Ivan Ivanov (suricactus)]

Hello, I have the exact same problem. The indicator updates every 250 ms and there are 730MB of RAM usage for 3-4 days. Once it get over 1.3 GB. It happens on Ubuntu 12.10 64bit Unity DE. Thanks.

[Wilhelm Schuster (wilhelm-schuster-95-n)]

I have set the update rate to 500ms.

[Michael Hofmann (mh21)]

Could you try the version at https://code.launchpad.net/~indicator-multiload/+archive/daily ?

It contains code that restarts the indicator if its RSS (resident) memory use exceeds 50MB.

[Wilhelm Schuster (wilhelm-schuster-95-n)]

I'll try it out. Although it seems to be only a quick hack. Is there a way I can log memory allocation or method calls or something like that?

[Michael Hofmann (mh21)]

It's the only thing that came to my mind to solve it.

I suppose there are some leaks in the communication between libappindicator and unity, but I'm not aware of anything I could do about it.

The command above is the best way to monitor memory usage:
  while sleep 60; do ps uh -p `pgrep -f indicator-multiload`; done

If you want to see where memory is used, use
  valgrind --num-callers=50 --leak-check=full --tool=memcheck /usr/bin/indicator-multiload

The results will be better if you install a couple of -dbg packages, see https://wiki.ubuntu.com/DebuggingProgramCrash.