touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #28436
[Bug 1384384] [NEW] memory leak - /usr/lib/x86_64-linux-gnu/indicator-keyboard-service --use-gtk
Public bug reported:
indicator-keyboard:
Installed: 0.0.0+14.04.20140410.1-0ubuntu1
Candidate: 0.0.0+14.04.20140410.1-0ubuntu1
Version table:
*** 0.0.0+14.04.20140410.1-0ubuntu1 0
500 http://mirrors.cat.pdx.edu/ubuntu/ trusty/main amd64 Packages
100 /var/lib/dpkg/status
*******begin******
from htop - take a look at RES as time goes by:
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
34613 lightdm 20 0 665M 216M 8792 S 27.2 0.1 3:48.53 /usr/lib/x86_64-linux-gnu/indicator-keyboard-service --use-gtk
a little later
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
34613 lightdm 20 0 697M 248M 8792 S 26.1 0.1 5:38.43 /usr/lib/x86_64-linux-gnu/indicator-keyboard-service --use-gtk
and again later
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
34613 lightdm 20 0 783M 307M 8796 S 0.0 0.1 10:23.49 /usr/lib/x86_64-linux-gnu/indicator-keyboard-service --use-gtk
this is roughly 50% growth. Probably not required for this
application...
The thing is that I noticed this this this morning because RES actually said: 12.8 GIG. *zomg*
That seems excessive for a keyboard indicator.
It appears to be reading the same file over and over and again but
perhaps not doing so correctly.
Using strace we can see that while there are just as many munmap as
mmaps:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
56.48 0.553369 5590 99 wait4
37.95 0.371828 3756 99 clone
1.90 0.018603 1 17771 poll
1.76 0.017267 1 26659 17672 recvmsg
0.88 0.008589 1 8835 writev
0.21 0.002027 1 3002 read
0.12 0.001182 1 867 198 open
0.12 0.001173 2 669 munmap
0.08 0.000789 1 606 63 futex
0.08 0.000739 4 198 unlink
0.07 0.000655 1 443 write
0.07 0.000641 1 669 mmap
0.06 0.000594 1 654 58 stat
0.05 0.000490 1 703 close
0.05 0.000482 1 693 lseek
0.04 0.000414 1 654 fstat
0.04 0.000365 1 387 access
0.02 0.000233 233 1 restart_syscall
0.02 0.000166 1 198 198 lstat
0.02 0.000160 2 96 pwrite
0.00 0.000036 1 33 eventfd2
0.00 0.000000 0 1 recvfrom
0.00 0.000000 0 2 getdents
0.00 0.000000 0 1 openat
------ ----------- ----------- --------- --------- ----------------
100.00 0.979802 63340 18189 total
So perhaps it is leaking with more traditional mallocs.
In any event, over time, this thing consumes massive quantities of memory, which is probably a bug.
** Affects: unity (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity in Ubuntu.
https://bugs.launchpad.net/bugs/1384384
Title:
memory leak - /usr/lib/x86_64-linux-gnu/indicator-keyboard-service
--use-gtk
Status in “unity” package in Ubuntu:
New
Bug description:
indicator-keyboard:
Installed: 0.0.0+14.04.20140410.1-0ubuntu1
Candidate: 0.0.0+14.04.20140410.1-0ubuntu1
Version table:
*** 0.0.0+14.04.20140410.1-0ubuntu1 0
500 http://mirrors.cat.pdx.edu/ubuntu/ trusty/main amd64 Packages
100 /var/lib/dpkg/status
*******begin******
from htop - take a look at RES as time goes by:
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
34613 lightdm 20 0 665M 216M 8792 S 27.2 0.1 3:48.53 /usr/lib/x86_64-linux-gnu/indicator-keyboard-service --use-gtk
a little later
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
34613 lightdm 20 0 697M 248M 8792 S 26.1 0.1 5:38.43 /usr/lib/x86_64-linux-gnu/indicator-keyboard-service --use-gtk
and again later
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
34613 lightdm 20 0 783M 307M 8796 S 0.0 0.1 10:23.49 /usr/lib/x86_64-linux-gnu/indicator-keyboard-service --use-gtk
this is roughly 50% growth. Probably not required for this
application...
The thing is that I noticed this this this morning because RES actually said: 12.8 GIG. *zomg*
That seems excessive for a keyboard indicator.
It appears to be reading the same file over and over and again but
perhaps not doing so correctly.
Using strace we can see that while there are just as many munmap as
mmaps:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
56.48 0.553369 5590 99 wait4
37.95 0.371828 3756 99 clone
1.90 0.018603 1 17771 poll
1.76 0.017267 1 26659 17672 recvmsg
0.88 0.008589 1 8835 writev
0.21 0.002027 1 3002 read
0.12 0.001182 1 867 198 open
0.12 0.001173 2 669 munmap
0.08 0.000789 1 606 63 futex
0.08 0.000739 4 198 unlink
0.07 0.000655 1 443 write
0.07 0.000641 1 669 mmap
0.06 0.000594 1 654 58 stat
0.05 0.000490 1 703 close
0.05 0.000482 1 693 lseek
0.04 0.000414 1 654 fstat
0.04 0.000365 1 387 access
0.02 0.000233 233 1 restart_syscall
0.02 0.000166 1 198 198 lstat
0.02 0.000160 2 96 pwrite
0.00 0.000036 1 33 eventfd2
0.00 0.000000 0 1 recvfrom
0.00 0.000000 0 2 getdents
0.00 0.000000 0 1 openat
------ ----------- ----------- --------- --------- ----------------
100.00 0.979802 63340 18189 total
So perhaps it is leaking with more traditional mallocs.
In any event, over time, this thing consumes massive quantities of memory, which is probably a bug.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1384384/+subscriptions
Follow ups
References
