memory leak in unity-panel-service

[Scott Moser]

top sorted by memory on my system right now shows:
top - 11:28:46 up 26 days, 15:58, 16 users, load average: 0.15, 0.21, 0.49
Tasks: 280 total, 1 running, 276 sleeping, 0 stopped, 3 zombie
Cpu(s): 19.8%us, 3.8%sy, 0.0%ni, 75.3%id, 1.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 3941584k total, 3689220k used, 252364k free, 136040k buffers
Swap: 4096536k total, 783324k used, 3313212k free, 888748k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29131 smoser 20 0 1939m 925m 21m S 34 24.0 292:02.57 firefox
15273 smoser 20 0 1831m 448m 14m S 2 11.7 86:51.58 unity-2d-shell
15329 smoser 20 0 701m 134m 6412 S 0 3.5 10:26.07 unity-panel-ser
16495 smoser 20 0 446m 48m 1520 S 0 1.3 1:04.42 deja-dup-monito
32551 smoser 20 0 496m 46m 7892 S 0 1.2 121:52.35 xchat

$ ls -l /proc/15329/{cmdline,exe}
-r--r--r-- 1 smoser smoser 0 Mar 15 22:08 /proc/15329/cmdline
lrwxrwxrwx 1 smoser smoser 0 Mar 16 08:02 /proc/15329/exe -> /usr/lib/unity/unity-panel-service (deleted)

That shows that this has been since upgraded, and that it has been up for ~ 3 weeks.
Looking at my apt logs, then this bug is actually against 5.6.0-0ubuntu4 , but I'm filing it anyway, as waiting 3 weeks to see if I see this problem again probably isn't going to help anyone.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: unity-services 5.8.0-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-18.28-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
ApportVersion: 2.0-0ubuntu4
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,compiztoolbox,decor,snap,commands,mousepoll,grid,move,place,imgpng,session,vpswitch,resize,regex,gnomecompat,unitymtgrabhandles,wall,resizeinfo,animation,workarounds,fade,scale,expo,ezoom,unityshell]
Date: Thu Apr 5 11:14:22 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: unity
UpgradeStatus: Upgraded to precise on 2011-11-07 (150 days ago)

[Sebastien Bacher (seb128)]

Thank you for your bug report, quite some leaks got fixed since you reported the issue, is that still happening? Could you get a valgrind log for it?

[Scott Moser (smoser)]

I disagree with the response here for the following reasons:
 * marking it 'invalid' so it will magically go away isn't helpful for anyone
 * suggesting that I should log out of my currently running environment, and run valgrind on my system for the next 2 weeks because you find that unreasonable to do yourself is somewhat rude
 * marking a memory leak of 420M over 3 weeks as 'low' is troubling.

You probably will get your desired result of making this bug go away, as I'm not likely to run my desktop under valgrind for a extended period of time.

I realize that the bug was reported against old versions, and understand the desire to see if it is still relevant.

My currently running environment has unity-panel-service up for ~ 10 days and it has a footprint of 42M (per top) at the moment. I believe that likely there is still a leak shown there. However, it was not being used for a significant portion of that as I was travelling. So, my finger-in-the-wind assessment is that you have fixed some memory leaks, but that it is still leaking. Again, having run the desktop for 10 days, my running versions are out of date, so even that data is not 100% relevant any more.

I really would feel much better if you were running valgrind in some automated fashion for extended periods of time on the components of Unity.

[Sebastien Bacher (seb128)]

> * marking it 'invalid' so it will magically go away isn't helpful for anyone

it's not marked "invalid", it's marked "incomplete" as "needs extra infos, we can't do a lot without that"

> * suggesting that I should log out of my currently running environment, and run valgrind on my system for the next 2 weeks because you find that unreasonable to do yourself is somewhat rude

assuming that others are lazy is somewhat rude, did you consider that maybe it's specific to your setups or that others don't get the issue and can't collect the infos from your system?

> * marking a memory leak of 420M over 3 weeks as 'low' is troubling.

well as said before some leaks got fixed since you opened your bug report so the number is likely to be lower, few users let their system run over 3 weeks without reboot (we usually get kernel updates that require a reboot at least once a month), and it's easy to "workaround" (the panel service is only a standalone service that can be restarted without closing your session or anything)

> You probably will get your desired result of making this bug go away, as I'm not likely to run my desktop under valgrind for a extended period of time.

did you read the code of conduct recently? what happened to assuming that people mean well?

> My currently running environment has unity-panel-service up for ~ 10 days and it has a footprint of 42M (per top) at the moment. I believe that likely there is still a leak shown there.

what number are we talking about in top? res? shr? yeah, it seems to leak 1mb a day, it's not perfect but it's barely a rc bug, knowing that it could well be that you use a non default indicator (do you run multiload, weather, or any indicator not installed by default?)

[Sebastien Bacher (seb128)]

Discussing on IRC, we have some known leaks but most have been fixed, the issue is likely coming from an indicator but without a valgrind log it's hard to figure which one...

[Scott Moser (smoser)]

I apologize for my rant.
I've got valgrind running on my unity-panel-service now, by doing this:
  sudo mv /usr/lib/unity/unity-panel-service /usr/lib/unity/unity-panel-service.real
  sudo ln -sf unity-panel-service.wrap /usr/lib/unity/unity-panel-service
  cat <<"EOF" | sudo tee -a /usr/lib/unity/unity-panel-service.wrap
#!/bin/sh
me=${0##*/}
rname="$me.real"
real=$(which "$rname" 2>/dev/null)
[ -z "$real" ] || { [ -x "${0%/*}/${rname}" ] && real="${0%/*}/$rname"; }
[ -n "$real" ] || { echo "FAILED TO FIND real: ${rname}"; exit 1; }

G_SLICE=always-malloc G_DEBUG=gc-friendly \
exec valgrind -v --tool=memcheck --leak-check=yes --num-callers=38 \
   --log-file=${HOME:-/tmp}/${USER:+${USER}-}${me}.log \
   "$real"
EOF
  sudo chmod 755 /usr/lib/unity/unity-panel-service

(most of that is just for my future reference. i will post back with more info).

[Scott Moser (smoser)]

$ dpkg-query --show unity-services
unity-services 5.10.0-0ubuntu6

Attached is a valgrind log for ~ 24 hours using the above version, showing:

==28208== LEAK SUMMARY:
==28208== definitely lost: 34,549 bytes in 419 blocks
==28208== indirectly lost: 65,745 bytes in 2,510 blocks
==28208== possibly lost: 6,890,632 bytes in 96,180 blocks
==28208== still reachable: 13,121,484 bytes in 218,112 blocks
==28208== suppressed: 0 bytes in 0 blocks

So it is still leaking according to valgrind but not on the same order of magnitude as the original bug was opened.

[Scott Moser (smoser)]

Running since May 3 (18 days now), unity-panel-service is 400M of resident memory.
The executable running is from 5.10.0-0ubuntu6 (precise release).

So, there is still significant memory leak there.

[Daniel van Vugt (vanvugt)]

Scott, using valgrind to find memory bloat (which might not be memory leaks) is often misleading and inaccurate. The valgrind tool for measuring boat is "massif". Please try that (valgrind --tool=massif).

Also, obviously, if you're running any non-standard indicators then please say so. Or just attach a copy of:
    /proc/`pidof unity-panel-service`/maps

[Scott Moser (smoser)]

I've just rebooted, so I don't have this in front of me any more.
I don't run any non-standard indicators. I have an external (to the laptop) monitor and I run unity-2d.
Indicators I have (sorry for ignorance here):
 * mail envelope (messaging) : ** this has xchat-indicator in it
 * battery (configured to show percentage)
 * bluetooth icon
 * network manager
 * volume/sound
 * date (configured with Month and Day of Month
 * "Me menu"

i honestly think the only thing that isn't installed by default is xchat-indicator.
So, I really don't see how I could be an oddball here.
If you're telling me that you have desktop uptime in the time frame of weeks, and still have unity-panel-2d with memory resident in the 20-30M range, then I'm willing to try to help out. However, if you're telling me that you haven't tried to debug this stuff personally over the course of days or weeks, then I'd rather not be a guinea pig and interrupt my normal work.

[h1bymask (h1bymask)]

The same on my PC. Top output:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3213 h1bymask 20 0 1068m 189m 3356 S 4 2.5 401:09.53 /usr/lib/unity/unity-panel-service

Ubuntu 12.04.2 LTS
indicator-application: 0.5.0-0ubuntu10.5.0-0ubuntu1
unity: 5.18.0-0ubuntu2

[James Troup (elmo)]

I'm still seeing this with Ubuntu 14.10:

 3381 james 20 0 825M 219M 11672 S 0.5 2.8 1h10:23 /usr/lib/unity/unity-panel-service

I've attached /proc/`pidof unity-panel-service`/maps

[Andrea Azzarone (azzar1)]

unity-panel-service is not leaking memory on 15.04+. The memory footprint tends to grow slowly but that does not mean there is actually a memory leak, it's just the way the kernel manages the memory. Please reopen the bug if you think the leak is still there.

[Arno Mühren (arnomuhren)]

This bug affects me on Ubuntu 16.10, after upgrading from 16.04.
Keeping my computer on simply results in unity-panel-service to use up all memory.

[Daniel Podlejski (underley)]

+1 (also after upgrade from 16.04)