memory leak in unity-2d-panel and indicator-multiload

I left the system basically un-used, over night, came back to it and now i'm showing 780M resident, and 1280M virtual.

$ dpkg-query --show unity-2d-panel
unity-2d-panel 5.2.0-0ubuntu1

top shows
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 3936 smoser 20 0 1989m 1.2g 20m S 32 31.3 229:41.50 firefox
 2951 smoser 20 0 726m 285m 8232 S 1 7.3 30:36.61 unity-2d-panel

after not much more than 1 day up and general desktop usage, we've got 285m of RES memory for unity-2d-panel.

In #ayatana [1] It was suggested that indicator-multiload might be related, and requested that I see if the problem still arises. there was previously a bug in this area that is marked fix-released (bug 779717).

So, I've disabled indicator-multiload, logged out, and logged back in.

Upon login, top reports the following usage for unity-2d-panel:
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 5382 smoser 20 0 553m 49m 27m S 0 1.3 0:01.57 unity-2d-launch
 5744 smoser 20 0 280m 48m 11m S 0 1.2 0:02.07 ubuntuone-syncd
 5381 smoser 20 0 441m 30m 20m S 2 0.8 0:00.73 unity-2d-panel

$ cat /proc/$(pidof unity-2d-panel)/statm
113222 8303 5342 10 0 22611 0

I'll try to remember to report back in 4 hours or so and see if this has changed.

--
[1] http://irclogs.ubuntu.com/2012/01/19/%23ayatana.html#t13:45

after letting this run for ~ 6 hours, i have /proc/<pid>/statm output for almost that entire time.
I'm now seeing a 'top' report of:
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 7473 smoser 20 0 562m 64m 26m S 0 1.7 0:07.32 unity-2d-places
 5382 smoser 20 0 571m 51m 26m S 0 1.3 0:41.79 unity-2d-launch
 5423 smoser 20 0 396m 37m 9m S 8 1.0 1:01.63 unity-panel-ser
 5381 smoser 20 0 507m 35m 20m S 2 0.9 0:49.17 unity-2d-panel

So it seems I've jumped in RES memory by 5M. statm now looks like:
130041 9374 5327 10 0 39430 0

the log that i have of statm output is generally pretty stable except for:
2012-01-19 19:33:10: 113405 8771 5326 10 0 22794 0
2012-01-19 19:34:10: 113405 8771 5326 10 0 22794 0
2012-01-19 19:35:10: 129789 9100 5326 10 0 39178 0
2012-01-19 19:36:10: 129789 9239 5326 10 0 39178 0

At that point the 'data + stack' (see man proc) increased dramatically. I'm not sure whether or not that correlated with the growth in RES. I really need to read more on memory use, I'm not sure all this is that useful.

However, in a nutshell, my memory footprint reported by 'RES' in top did climb 5M over the course of 6 hours *without* indicator-multiload running.

ok, so over probably 24 hours, I had RES sitting at 33M or so. So I do suspect that the really bad leak is a result of indicator-multiload.

Chatting on IRC, we still suspect a leak could exist, so we'll do a little profiling on unity-2d-panel to check.

I went without indicator-multiload for several days and did not see significant increase in memory.
I turned it back on yesterday, and it is now 120M RES in top. So, this is almost certainly caused by indicator-multiload.
I've added the ubuntu package for indicator-multiload to this bug.

$ u2dp=$(pidof unity-2d-panel)
$ cat /proc/$u2dp/statm
140018 30931 2236 10 0 49395 0
$ cat /proc/$u2dp/status
Name: unity-2d-panel
State: S (sleeping)
Tgid: 9109
Pid: 9109
PPid: 8987
TracerPid: 0
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 64
Groups: 4 20 24 46 116 118 124 127 133 1000
VmPeak: 583612 kB
VmSize: 560356 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 124364 kB
VmRSS: 124136 kB
VmData: 197728 kB
VmStk: 136 kB
VmExe: 40 kB
VmLib: 74420 kB
VmPTE: 904 kB
VmSwap: 3252 kB
Threads: 2
SigQ: 0/30610
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000180010000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 3239988
nonvoluntary_ctxt_switches: 848856

Status changed to 'Confirmed' because the bug affects multiple users.

I suspect there is about zero percent chance of this being fixed, right?
it basically means you cannot run (at least I cannot run) indicator-multiload unless you're logging in and out frequently.

I have this issue as well on 12.04 beta. Indicator-multiload gets to 1.3GB of memory over a single weekend.

Is this bug a duplication of this bug?

https://bugs.launchpad.net/indicator-multiload/+bug/779717

Dave,
  That bug is marked fix-released in unity and ubuntu. Its possible that bug 779717 was incorrectly marked as fix-released (ie, not actually tested). But rather than appending information to a fixed bug, this bug should track future work.

  Regarding 12.04 with indicator multiload causing memory leak, this is a known issue. My solution has been to stop using indicator multi-load, although I really miss it.

Just wanted to add another confirmation to the thread. I'm using 12.04 with Unity 2D, and indicator-multiload uses over 1 GB RAM after the weekend. Killing it frees all the memory, and I relaunch it.

how is this bug different from bug 1049282 & bug 956810?

also affects unity and not only 2d. workaround so far is do not use indicator-multiload or kill process and keep restarting if you do need to use it.

I just hit this after 18 days of uptime wondering what the heck was eating my memory:
 3173 arges 20 0 6669m 5.7g 3400 S 1 36.8 274:43.01 indicator-multi

Not sure if we could run some tools like valgrind on these processes to see where the leak is occurring.

> Not sure if we could run some tools like valgrind on these processes to see where the leak is occurring.

That's been done in bug 956810, which was marked as a duplicate of this one. I do believe the leak is in libdbusmenu. It shows up in indicator-multiload because the indicator changes its menu items a *lot* more than most applications.

@Kevin:

If that's the case, then there's an easy workaround. In the preferences, it's possible to remove all the status information from the menu, which I've done since I considered it distracting. I haven't observed any leaks since that time.

Well I finally decided to report this bug and here it is. :/ darn shame that no fix has been submitted yet. I enjoy this indicator very much and the alternative is just lacking in functionality.

Noticed this morning that my desktop wa rather slow. according to atop indicator-multiload is using vsize 7.3G, rsize 3.2G.

I'm also STILL affected by this... 12.10 64bit.
Changing the width of the indicator-multiload to 30 pixels does not help.
Increasing the update interval makes things worse.

This has been around since May-2011. Too bad it's still untackled...

This may be a duplicate:
https://bugs.launchpad.net/indicator-multiload/+bug/1030293

Also I'm not sure unity-2d is realted, I've been able to reproduce this issue in regular unity. And on raring/quantal/precise.

Status changed to 'Confirmed' because the bug affects multiple users.

Chris,
  What is the runaway process when you see this in unity ? The subject just says unity-2d-panel because that is the process that was showing the massive footprint in unity-2d. We should update the subject and/or description.

Also, for anyone looking to actually debug the leak, there appears some good work done in bug 956810 as to the cause.

@smoser,
The runaway process was indicator-mutli as it was the process consuming the most memory (5.7G) in one case.

FWIW, I've also run valgrind on indicator-multiload using:
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --track-origins=yes --log-file=valgrind.log /usr/bin/indicator-multiload

I'll attach this log if it helps somebody with debugging.

In https://bugs.launchpad.net/ubuntu/+source/indicator-multiload/+bug/956810/comments/7, @keturn mentions a patch that could have introduced a memory leak in libdbusmenu. This would be a good experiment to try and revert this patch and see if the memory leaks persist (or at least the egregious offenders).

It's affects me too on precise with all updates.

 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 7114 db 20 0 1240m 531m 36m R 25 16.3 375:53.06 firefox
29088 db 20 0 460m 151m 16m R 8 4.6 199:49.71 compiz
11431 db 20 0 2852 1144 848 R 4 0.0 0:00.03 top
30788 db 20 0 226m 83m 7732 S 4 2.6 93:10.17 unity-panel-ser
 1147 root 20 0 88720 22m 3756 S 2 0.7 428:57.43 Xorg
 1855 db 20 0 8728 4028 600 S 2 0.1 86:00.61 dbus-daemon
 1989 db 20 0 104m 44m 2400 S 2 1.4 142:11.47 hud-service
 2085 db 20 0 180m 19m 7244 S 2 0.6 12:06.50 gnome-terminal
 2641 db 20 0 223m 53m 9740 S 2 1.6 40:40.86 xchat
 6731 db 20 0 552m 412m 10m S 2 12.6 11:26.98 indicator-multi

I also see similar issue and found the bug report here.
If I kill the multload indicator and restart it, the system memory consumption restored to normal level.

I fear there is nothing that can be done from the indicator side. The leak is related to the dbus communication, which is done by libappindicator.

So what is the bug number for the libappindicator bug? We should be commenting on that one and marking it as affecting us to increase the priority/heat

I don't know whether there exists a bug for this precise problem.
Relevant valgrind logs are at https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/905854/comments/26 and https://bugs.launchpad.net/indicator-multiload/+bug/1101810/comments/5.

I will implement sth. to restart the indicator if it leaks too much memory, but this will only help with memory leaks in the libraries that the indicator uses, not with leaks that are in unity(-2d), hud etc.

This bug was fixed in the package indicator-multiload - 0.3-0ubuntu1

---------------
indicator-multiload (0.3-0ubuntu1) raring; urgency=low

  * New upstream release.
  * Fixes LP: #926399, #823141, #891428, #905854, #962646, #1015623.
  * debian/patches: Remove ensure_dirs_exist.patch, fixed upstream.
  * debian/compat, debian/control: Increase debhelper version to 8.
  * debian/watch: Fix download location for new upstream versions.
  * debian/copyright: Fix license text, copyright years, email.
 -- Michael Hofmann <email address hidden> Sat, 16 Feb 2013 17:50:35 +0100

This happens for me in Ubuntu 12.04 Precise on amd64.
indicator-multiload version 0.2-0ubuntu1.
After a month it was using >7G of ram.

Please use the version at ppa:indicator-multiload/stable-daily or in Ubuntu 13.04, there this is more or less fixed (restart on excessive leaks).

Related "indicator-multiload causes a memory leak in compiz when run under unity" #779717 bug contains the similar information but has the higher bug heat value. No fix for the indicator-multiload there though.
BTW the solution provided here (restart on big memory consumption) is actually a workaround, it's definitely not a fix.

xubuntu 14.04 xfce (libindicator-plugin.so)
indicator-multiload memory leak still present.
System has been up for 7 days and 13 hours and memory usage is 1373MB.

Xubuntu 16.04.1 x86_64
uptime: 7 days
/usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libindicator-plugin.so 454M (RES via htop)

I think the problem with libindicator-plugin.so still exists.