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 [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel