memory leak - /usr/lib/x86_64-linux-gnu/indicator-keyboard-service --use-gtk

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.