hud memory usage grows over time

Bug #1253593 reported by Vladimir Rutsky
100
This bug affects 21 people
Affects Status Importance Assigned to Milestone
hud (Ubuntu)
Fix Released
Undecided
Pete Woods

Bug Description

After five days of uptime hud-service used 749 MB of RAM.

Restarting hud-service drops it memory usage to about 100-150 MB, on the next day it's using already 227 MB of RAM.

I'm using Ubuntu 13.10 for developing Qt-based application. Most of the time following applications started and used:
Qt Creator, Qt Linguist, Qt Designer;
gnome-terminal;
gitk, git gui, cmake-gui;
Firefox;
Pidgin.

In the tray there are:
System Load Indicator,
Nagstamon (v0.9.11 from official site),
shutter,
remmina.

Also I use Yandex.Music and Grooveshark web-apps.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: hud 13.10.1+13.10.20131031-0ubuntu1
ProcVersionSignature: Ubuntu 3.8.0-32.47-generic 3.8.13.10
Uname: Linux 3.8.0-32-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
Date: Thu Nov 21 14:29:59 2013
InstallationDate: Installed on 2013-10-16 (35 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MarkForUpload: True
SourcePackage: hud
UpgradeStatus: Upgraded to saucy on 2013-11-07 (13 days ago)

Related branches

Revision history for this message
Vladimir Rutsky (rutsky-vladimir) wrote :
Revision history for this message
Antti Kaijanmäki (kaijanmaki) wrote :

@rutsky-vladimir

Thanks for the report!
Are you actually using HUD to search for actions and such?

Also, next time when you see hud-service consuming a lot of memory could you provide the information from /proc/$pid/status

You can get the value for $pid using ps. On my system for example I would get it by:
$ ps aux |grep hud-service
antti 2070 0.0 0.1 360484 9004 ? Ssl marras20 0:08 /usr/lib/x86_64-linux-gnu/hud/hud-service

the $pid is the second value: 2070 for me, so
$ cat /proc/2070/status > status.txt

and attach the status.txt to this bug report.

Thanks!

Changed in hud (Ubuntu):
status: New → Incomplete
Revision history for this message
Vladimir Rutsky (rutsky) wrote :

I use HUD only to launch small set of programs, like gnome-terminal, Qt Creator etc. I don't use it for file/music or other search.

How much memory should be considered "a lot" for hud-service?
On Ubuntu 12.04 hud-service uses only 7 MB of RAM, and on 13.10 hud-service just after start eats more than 100 MB of RAM.

Attaching current /proc/pid/status (hud service use 174 MB of RAM and about 10 hours earlier was 120 MB).

Revision history for this message
Vladimir Rutsky (rutsky) wrote :

I monitored memory usage for a day and noticed stable memory usage increasing.

Attaching log of memory usage over time generated with

while true; do watch -g -n 1 ps -o rss -o size -o vsize $(pgrep hud-service); echo `date -Iseconds` `ps --no-header -o rss -o
 size -o vsize $(pgrep hud-service)` >> log.txt; sleep 1; done

File contains <time, "resident set size" (KB), "memory size" (KB), "total VM size" (KB)> rows (first few rows doesn't contain last two columns, I decided to include them later during monitoring, when realized that hud-service memory usage "drops" when other processes (e.g. g++) allocates a lot of memory).

In this log you can see, that after some time hud-service starts to constantly eat memory about 20 MB per hour.

During logging from start till around 22:30 (GMT+4) I was using computer interactively, after that computer was locked and no extensive work was done on it.

Revision history for this message
Vladimir Rutsky (rutsky) wrote :

Add /proc/`pgrep hud-service`/status corresponing to end of log.

Revision history for this message
Alan Pope 🍺🐧🐱 🦄 (popey) wrote :

hud-service is eating up RAM on my laptop after being up for 4 days..

alan@deep-thought:~$ cat /proc/3989/status
Name: hud-service
State: S (sleeping)
Tgid: 3989
Pid: 3989
PPid: 3819
TracerPid: 0
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 64
Groups: 4 20 24 27 30 46 109 124 128 141 1000
VmPeak: 2192732 kB
VmSize: 2145408 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 712768 kB
VmRSS: 481524 kB
VmData: 2008396 kB
VmStk: 136 kB
VmExe: 276 kB
VmLib: 35052 kB
VmPTE: 3632 kB
VmSwap: 1241460 kB
Threads: 3
SigQ: 0/62721
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000180004000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000001fffffffff
Seccomp: 0
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 4040014
nonvoluntary_ctxt_switches: 1248328

Changed in hud (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Pete Woods (pete-woods) wrote :

Thanks for this report guys. I am close to completing a significant overhaul to HUD, which should put a lid on these recurring memory leak issues.

The reason you are seeing increased memory usage under normal conditions is because HUD had a voice recognition capability integrated into it for 13.10. This is never used on the desktop (it's only used on the phone), but because of the way I integrated it, it's running even though you can't actually use it with the "legacy" Unity7 user interface.

Obviously this doesn't totally account for HUD using several hundred megabytes of memory. This is simply down to old fashioned memory leaks.

In addition to a less leak-prone design, the revisions to HUD include splitting the voice engine out into its own service, which will only be started on the phone. Thus, your memory usage should go back down to similar levels as in 12.04.

Pete Woods (pete-woods)
Changed in hud (Ubuntu):
status: Confirmed → Fix Committed
assignee: nobody → Pete Woods (pete-woods)
Revision history for this message
Tessa (unit3) wrote :

I don't normally "me too!" on bugs, but note that I'm seeing usage of 2.1G and still climbing after leaving my desktop running over the weekend, so I'd say this is pretty critical to get a fix out into 13.10.

In the mean time, is there a workaround to reset / restart hud-service without killing the login session?

Revision history for this message
pcworld (pcworld) wrote :

> In the mean time, is there a workaround to reset / restart hud-service without killing
> the login session?
I think you can just kill the hud-service process, it will spawn a new one.

Revision history for this message
Tessa (unit3) wrote :

Ahhhh, yeah, "killall hud-service" works and seems nondestructive. Great, putting that in cron.daily until this is resolved, thanks.

Charles Kerr (charlesk)
Changed in hud (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
jaime.undurraga (jaime-undurraga) wrote :

The problem seems to continue. hud-service is using 85% of my memory (I have 32 GB !!) and 100% CPU. killall or kill does not kill it.

 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20208 jundurr+ 20 0 27.839g 0.026t 5588 R 100.4 85.6 2597:47 hud-service
32571 jundurr+ 20 0 1091560 85016 11632 R 100.4 0.3 7:12.80 cli
 2872 jundurr+ 20 0 1644164 71668 7820 S 13.6 0.2 1306:04 nautilus
 1412 root 20 0 723080 278368 67204 S 9.0 0.8 803:47.22 Xorg

$cat /proc/20208/status
Name: hud-service
State: R (running)
Tgid: 20208
Ngid: 0
Pid: 20208
PPid: 2297
TracerPid: 0
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 64
Groups: 4 7 20 24 27 30 44 46 108 124 125 1000 1001
VmPeak: 29168484 kB
VmSize: 29116280 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 28192764 kB
VmRSS: 28192764 kB
VmData: 28748660 kB
VmStk: 136 kB
VmExe: 592 kB
VmLib: 97924 kB
VmPTE: 56096 kB
VmSwap: 145496 kB
Threads: 4
SigQ: 0/256813
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000180014002
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000001fffffffff
Seccomp: 0
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 207053
nonvoluntary_ctxt_switches: 25634077

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.