smem report from the nexus-raring

[Colin Watson]

On Mon, Jan 28, 2013 at 09:06:41PM +0100, Sebastien Bacher wrote:
> We recently did a smem memory snapshot from raring, running on a
> nexus tablet. The results have been recorded on the wiki:
> https://wiki.ubuntu.com/Nexus7/Smem-2013-01-16

I've been spending some time trying to track down memory leaks this
week.  Here are a few notes.

valgrind was of course the first thing I reached for.  I had to fix a
few things (you used to need valgrind-dbg to get useful stack traces on
ARM, and a fairly common instruction wasn't implemented), so make sure
you have the most current valgrind in raring.  It's not perfect for
desktop stuff, because it's unaware of GObject references, and because
GTK+ allocates quite a few singleton structures which remain unfreed on
exit; I hear refdbg can help, but I haven't tried that yet.  However, if
you decide you don't care about reference cycles or unfreed singletons
(which I think is not necessarily a bad approach, at least to start
with), the --show-possibly-lost=no option can help cut the output down
to something more reasonable.

I ran across https://fedorahosted.org/gdb-heap/, which is handy for
figuring out something of what's going on with running processes; I'm
working on packaging this, but in the meantime you can grab it from git
(I think I'd recommend that over the last release, as it's gained some
awareness of GTypes).  You can check it out in your home directory and
then do:

  $ sudo PYTHONPATH=/home/ubuntu/gdb-heap gdb /path/to/executable PID
  (gdb) python import gdbheap
  (gdb) heap
  ... then for example ...
  (gdb) heap select kind="string data"

Poking around here can give you a sense of where memory is going.  I
used a combination of this and valgrind to track down leaks in upower
(and sorry for the regression yesterday, caused by me unwisely applying
a small patch by hand); you can see the difference here:

  http://people.canonical.com/~j-lallement/N7/memusage/idle/upowerd.png

Caches are important, and they often rely on filesystem timestamps,
especially the ones that can only be built as root.  Unfortunately, the
Nexus 7 installer was failing to preserve timestamps, possibly due to a
false-economy attempt to make the installer run more quickly.  As a
result, for example, anything that loaded a GTK+ icon theme was
allocating several hundred KB of memory more than it needed to.  We've
fixed this now in the installer; if you don't want to reflash, then at
least run 'sudo update-icon-caches /usr/share/icons/*'.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]