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.
** Attachment added: "Short and long valgrind runs showing memory leak"
http://launchpadlibrarian.net/20389740/multirun-panel-2-valgrind-1.tar.gz
** Changed in: libgtop2 (Ubuntu)
Sourcepackagename: gnome-applets => libgtop2
--
multiload-applet-2 leaks memory
https://bugs.launchpad.net/bugs/307472
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
