Memory GN-Optimization tools, (libumem vs nautilus)

Tuesday May 31, 2005

In Robert Love's GNOME optimization talk at GUADEC, I thought I heard him say that Nautilus RSS grows by (10-12Mb?) on every folder open but that Valgrind hasn't found any leaks. Well, since libumem doesn't grind nautilus performance to a halt, there's no harm in me giving it a try. I didn't do anything fancy, I just followed followed Adam Leventhal's example replaced 'my_leaky_program' with Nautilus¹, set a breakpoint at nautilus_window_close::bp, opened and closed a nautilus folder. Most of the stuff I get is pretty generic strdup leaks, but here are a couple of the interesting bits:

::findleaks
CACHE     LEAKED   BUFCTL CALLER
{stuff deleted...}
080eb790      26 089f0c88 libc.so.1`strdup+0x25
080eba10      32 08979de8 libc.so.1`strdup+0x25
080eb510      25 089e6908 libc.so.1`strdup+0x25
...

The reason I pulled these three entries out of the findleaks output is that they all have an audit which looks something like this:

089790c8::bufctl_audit

            ADDR          BUFADDR        TIMESTAMP           THREAD
                            CACHE          LASTLOG         CONTENTS
         8979de8          8978348      e6fb39f5108                6
                          80eba10                0                0
                 libumem.so.1`umem_cache_alloc_debug+0x16c
                 libumem.so.1`umem_cache_alloc+0xe1
                 libumem.so.1`umem_alloc+0x3f
                 libumem.so.1`malloc+0x23
                 libc.so.1`strdup+0x25
                 libgnomevfs-2.so.0.600.0`_gnome_vfs_xdg_hash_append_glob+0xbe

Maybe a nautilus or gnome-vfs expert could tell me if these apparent leaks in _gnome_vfs_xdg_hash_append_glob represent a real problem.

I also wonder if nautilus-throbber has any leaks. Dtrace shows that it certainly does a lot of I/O considering it's only there to tell us that nautilus is busy.

Hmm, I'm missing Glynn's talk because my laptop sound is hosed. Oh cool, the Fluendo java plugin works fine on Sun Ray under Solaris, even with hotdesking. It honors AUDIODEV! Well, that's all I have for now. I'd appreciate hearing whether this or other similar information might help the GNOME optimization project.

Update:

Thanks Yusuf for suggesting that I add a link to the libumem tutorial.

¹ There isn't room in this blog for the number of leaks you'd find in certain other applications (you know who you are, don't you ;-)

Memory GN-Optimization tools, (mallocfree.d vs gconfd-2)

Tuesday May 31, 2005

Memory optimization also came up in Robert Loves GUADEC 6 talk. I already looked at pmap, but I promised BenM and Yusuf that I would write a quick tutorial on using Solaris memory profiling tools for GNOME. Sure, I thought, when am I going to have time to do that? Well, in the 15 minutes before I caught the train home on friday, I found Adam Leventhal's libumem primer and SMG's dtrace script which indicate the frequency malloc and free are called for each code path. In this example, I ran the script against gconfd-2 after launching and closing gnome-calculator.

Here's the script:

# cat mallocfree.d
#!/usr/sbin/dtrace -s

pid$1::free:entry,
pid$1::malloc:entry
/execname == "gconfd-2"/
{
        @[ustack(), probefunc] = count();
}

Here are the call stacks and number of calls of the top five code paths to free/malloc:

./mallocfree.d {process ID}
{stuff deleted}
              libc.so.1`free
              libglib-2.0.so.0.400.1`standard_free+0xc
              0x80d10b8
              0x1c0
              0x6e622f65
 free                                                            102

              libc.so.1`free
              libglib-2.0.so.0.400.1`standard_free+0xc
              libORBit-2.so.0.0.0`ORBit_POAObject_handle_request+0x35b
              0xff0cec83
  free                                                            116

              libc.so.1`free
              libglib-2.0.so.0.400.1`standard_free+0xc
              0xe810ec83
  free                                                            181

              libc.so.1`free
  free                                                            185

              libc.so.1`malloc
              libglib-2.0.so.0.400.1`standard_malloc+0xc
  malloc                                                          460