Comment 8 for bug 307472

Okay, attached are valgrind runs demonstrating this. Both short and long runs are included. It's pretty easy to see that this is the culpret:

==20188== 396,738 bytes in 7,110 blocks are definitely lost in loss record 213 of 215
==20188== at 0x4C266E1: realloc (vg_replace_malloc.c:429)
==20188== by 0x7103377: __vasprintf_chk (in /lib/libc-2.8.90.so)
==20188== by 0x6B91DAA: g_vasprintf (in /usr/lib/libglib-2.0.so.0.1800.2)
==20188== by 0x6B7E6A0: g_strdup_printf (in /usr/lib/libglib-2.0.so.0.1800.2)
==20188== by 0x504646F: linux_2_6_0 (fsusage.c:111)
==20188== by 0x50465FD: glibtop_get_fsusage_s (fsusage.c:168)
==20188== by 0x5040348: glibtop_get_fsusage_l (lib.c:835)
==20188== by 0x404636: GetDiskLoad (linux-proc.c:129)
==20188== by 0x404C70: load_graph_update (load-graph.c:130)
==20188== by 0x6B5D4FA: (within /usr/lib/libglib-2.0.so.0.1800.2)
==20188== by 0x6B5CD3A: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1800.2)
==20188== by 0x6B6050C: (within /usr/lib/libglib-2.0.so.0.1800.2)
==20188== by 0x6B60A3C: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1800.2)
==20188== by 0x761E8A5: bonobo_main (in /usr/lib/libbonobo-2.so.0.0.0)
==20188== by 0x761CC60: bonobo_generic_factory_main_timeout (in /usr/lib/libbonobo-2.so.0.0.0)
==20188== by 0x4E32580: panel_applet_factory_main_closure (in /usr/lib/libpanel-applet-2.so.0.2.46)
==20188== by 0x40579A: main (main.c:550)

Now, glibtop_get_fsusage_l doesn't return any dynamically-allocated stuff, so there's really no way the problem can be in the applet. Digging deeper, I get to here:

static void linux_2_6_0(glibtop *server, glibtop_fsusage *buf, const char *path)
{
        char *filename;
        const char *format;
        int ret;
        char buffer[BUFSIZ];
        char device[64];

        if (!get_device(server, path, device, sizeof device))
                return;

        get_sys_path(server, device, &filename, &format);

        ret = try_file_to_buffer(buffer, sizeof buffer, filename);

        if(ret < 0) return;

        if (sscanf(buffer, format, &buf->read, &buf->write) != 2) {
                glibtop_warn_io_r(server, "Could not parse %s", filename);
                return;
        }

        g_free(filename);

        buf->flags |= (1 << GLIBTOP_FSUSAGE_READ) | (1 << GLIBTOP_FSUSAGE_WRITE);
}

get_sys_path allocates memory into the 'filename' variable. However, there's a couple of error conditions which return without g_freeing it. I'm assuming that one of those is taken, which is causing the leak. (get_sys_path doesn't appear in the Valgrind trace because it's inlined. Nevertheless, that is where the memory is allocated.)

I'll change the package of this bug as it appears to belong to libgtop.