multiload-applet-2 leaks memory

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a valgrind log following the instructions at https://wiki.ubuntu.com/Valgrind and attach the file to the bug report. This will greatly help us in tracking down your problem.

That page does not explain how to run a Gnome applet under Valgrind. When I start it on the command line using the same arguments as show up in the ps output, it just prints out an IOR and does nothing else. I am at a loss of how I could proceed with this without further instruction.

Okay, I'm still not sure how to do the above, but I can't even run the debug-enabled binary in valgrind:

:; sudo apt-get install gnome-applets-dbgsym=2.24.1-0ubuntu1

:; G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=valgrind.log /usr/lib/debug/usr/lib/gnome-applets/multiload-applet-2
valgrind: m_ume.c: can't open interpreter

:; /usr/lib/debug/usr/lib/gnome-applets/multiload-applet-2
zsh: exec format error: /usr/lib/debug/usr/lib/gnome-applets/multiload-applet-2
:; ldd /usr/lib/debug/usr/lib/gnome-applets/multiload-applet-2
/usr/bin/ldd: line 117: /usr/lib/debug/usr/lib/gnome-applets/multiload-applet-2: cannot execute binary file

Maybe there's something wrong with the -dbgsym package?

Never mind. You might want to add instructions to the Wiki pages referenced above to say something like "Don't try to run the downloaded files in /usr/lib/debug, they are just debug symbols." I had never heard of the concept of this in Linux, and I have no idea how they are found. Nevertheless, it does work if you run the normal binary somehow.

i think Pedro was just helping you collect relevant data so we could look at why the bug happened and if it's reproducible on another machine so we could fix it more easily. I don't think he was saying the wiki would fix the problem, that happens later - i think.

Good luck with sorting this :)

Uh, I wasn't implying that. Only that I have a fair amount of experience as a Unix software developer, and I had trouble following the instructions on the Wiki page to get this debug information. There are two things that have confused me:

* The fact that the -dbgsym packages actually only provide extra debug information in files in /usr/lib/debug, and not whole new executables with debug information. I wasn't aware that this was possible, so when I saw it didn't modify the existing executables, and that /usr/bin/file said that the new /usr/lib/debug files were in fact ELF executables, the natural thing for me to do was to try to run them, which fails miserably. I was just asking for a hint to be placed on the wiki page to that effect, to prevent further confusion.

* The fact that this is a gnome-panel applet, and in fact the way to debug it is very non-obvious. The Ubuntu Valgrind wiki page contains nothing about how to do this. I finally found something here: http://www.davyd.id.au/articles/debugging-gnome-applets.shtml , but I think in general most bug reporters are not going to go to that much effort to find this out.

Anyway, it looks like the leak is possibly in libgtop or how it is called from the system applet. I'll post full valgrind dumps in a bit.

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.

Oh, now that this involved gtop, I suppose this would be helpful:

:; apt-cache policy libgtop2-7
libgtop2-7:
  Installed: 2.24.0-0ubuntu2
  Candidate: 2.24.0-0ubuntu2

Making the above linux_2_6_0 function g_free(filename) in all possible exit paths after its allocated does indeed fix the memory leak in the Gnome system monitor applet I'm seeing.

thank you for your work there

This bug was fixed in the package libgtop2 - 2.24.0-0ubuntu3

---------------
libgtop2 (2.24.0-0ubuntu3) jaunty; urgency=low

  * 50_linxu260_leak_fix.patch: Fix memory leak thanks to Brian Downing
    (LP: #307472).

 -- Kees Cook <email address hidden> Tue, 16 Dec 2008 09:56:24 -0800

Given that this is in fact a memory leak and will eventually OOM an Intrepid box, can we have a backport please?

Thank you for your help!But,I am sorry for my poor English,which,is not my
mother tongue!Hence,I don't know how to solve it!Can you give me some
solutions or tell me what I should do?

Thank you very much!

Best wishes!

2009/1/6 Brian J. Murrell <email address hidden>

> Given that this is in fact a memory leak and will eventually OOM an
> Intrepid box, can we have a backport please?
>
> --
> multiload-applet-2 leaks memory
> https://bugs.launchpad.net/bugs/307472
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "libgtop2" source package in Ubuntu: Fix Released
> Status in libgtop2 in Ubuntu Intrepid: New
> Status in libgtop2 in Ubuntu Jaunty: Fix Released
>
> Bug description:
> Binary package hint: gnome-applets
>
> multiload-applet-2 memory usage appears to grow without bounds:
>
> :; uptime
> 09:37:18 up 13 days, 20:46, 7 users, load average: 0.10, 0.27, 0.27
> :; ps auxw | grep multiload
> bdowning 14684 0.2 23.3 704516 480568 ? S Nov28 53:06
> /usr/lib/gnome-applets/multiload-applet-2
> --oaf-activate-iid=OAFIID:GNOME_MultiLoadApplet_Factory --oaf-ior-fd=25
> :; kill 14684
>
> (after it restarted)
>
> :; ps auxw | grep multiload
> bdowning 10424 2.0 0.4 190940 9876 ? S 09:35 0:00
> /usr/lib/gnome-applets/multiload-applet-2
> --oaf-activate-iid=OAFIID:GNOME_MultiLoadApplet_Factory --oaf-ior-fd=25
>
> (about 20 minutes later)
>
> :; ps auxw | grep multiload
> bdowning 10424 0.3 0.5 191560 10656 ? S 09:35 0:04
> /usr/lib/gnome-applets/multiload-applet-2
> --oaf-activate-iid=OAFIID:GNOME_MultiLoadApplet_Factory --oaf-ior-fd=25
>
> I did not open the system monitor window after I killed it, the memory
> growth happens over time naturally.
>
> :; lsb_release -rd
> Description: Ubuntu 8.10
> Release: 8.10
>
> :; dpkg -l | grep gnome-applets
> ii gnome-applets 2.24.1-0ubuntu1
> Various applets for GNOME 2 panel - binary f
> ii gnome-applets-data 2.24.1-0ubuntu1
> Various applets for GNOME 2 panel - data fil
>
> :; uname -m
> x86_64
>

I second Brian's request. I leave my Intrepid box running for a loooong time and right now the multiload applet is consuming 800MB (!) of resident memory:

  PID USER PR NI VIRT SWAP RES SHR S %CPU %MEM TIME P COMMAND
19855 derek 20 0 685m 197m 488m 9.9m S 2 8.3 293:36 0 multiload-apple
 8297 derek 20 0 520m 197m 323m 9.8m S 0 5.5 274:47 0 multiload-apple
13330 derek 20 0 635m 311m 323m 34m S 23 5.5 44,33 1 firefox-bin

It's outpaced firefox, which is really saying something!

Derek

Have you installed

libgtop2.7
libgtop2.2-common

Try System menu on the top taskbar - Administration - Synaptic Package Manager (near bottom of list)

It has a Search button

If you haven't got that one installed then maybe install it. If you already have it installed or if it didn't help then please let us know.

Good luck with this
Regards from
Tom :)

yes,I have installed

libgtop2.7

libgtop2.2-common

and I wanted to unstall them before,but it doesn't work!

Thank you for your help!

Best wishes!
2009/1/13 Tom <email address hidden>

> Have you installed
>
> libgtop2.7
> libgtop2.2-common
>
> Try System menu on the top taskbar - Administration - Synaptic Package
> Manager (near bottom of list)
>
> It has a Search button
>
> If you haven't got that one installed then maybe install it. If you
> already have it installed or if it didn't help then please let us know.
>
> Good luck with this
> Regards from
> Tom :)
>
> --
> multiload-applet-2 leaks memory
> https://bugs.launchpad.net/bugs/307472
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in libgtop: Fix Released
> Status in "libgtop2" source package in Ubuntu: Fix Released
> Status in libgtop2 in Ubuntu Intrepid: New
> Status in libgtop2 in Ubuntu Jaunty: Fix Released
>
> Bug description:
> Binary package hint: gnome-applets
>
> multiload-applet-2 memory usage appears to grow without bounds:
>
> :; uptime
> 09:37:18 up 13 days, 20:46, 7 users, load average: 0.10, 0.27, 0.27
> :; ps auxw | grep multiload
> bdowning 14684 0.2 23.3 704516 480568 ? S Nov28 53:06
> /usr/lib/gnome-applets/multiload-applet-2
> --oaf-activate-iid=OAFIID:GNOME_MultiLoadApplet_Factory --oaf-ior-fd=25
> :; kill 14684
>
> (after it restarted)
>
> :; ps auxw | grep multiload
> bdowning 10424 2.0 0.4 190940 9876 ? S 09:35 0:00
> /usr/lib/gnome-applets/multiload-applet-2
> --oaf-activate-iid=OAFIID:GNOME_MultiLoadApplet_Factory --oaf-ior-fd=25
>
> (about 20 minutes later)
>
> :; ps auxw | grep multiload
> bdowning 10424 0.3 0.5 191560 10656 ? S 09:35 0:04
> /usr/lib/gnome-applets/multiload-applet-2
> --oaf-activate-iid=OAFIID:GNOME_MultiLoadApplet_Factory --oaf-ior-fd=25
>
> I did not open the system monitor window after I killed it, the memory
> growth happens over time naturally.
>
> :; lsb_release -rd
> Description: Ubuntu 8.10
> Release: 8.10
>
> :; dpkg -l | grep gnome-applets
> ii gnome-applets 2.24.1-0ubuntu1
> Various applets for GNOME 2 panel - binary f
> ii gnome-applets-data 2.24.1-0ubuntu1
> Various applets for GNOME 2 panel - data fil
>
> :; uname -m
> x86_64
>

I believe I already have those packages installed and I'm definitely seeing a memory leak:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
un libgtop2 <none> (no description available)
un libgtop2-2 <none> (no description available)
un libgtop2-4 <none> (no description available)
un libgtop2-5 <none> (no description available)
ii libgtop2-7 2.24.0-0ubuntu gtop system monitoring library
ii libgtop2-commo 2.24.0-0ubuntu common files for the gtop system monitoring

On Tue, 2009-01-13 at 10:46 +0000, Tom wrote:
> Have you installed
>
> libgtop2.7
> libgtop2.2-common

There are no such packages in Intrepid:

$ apt-cache policy libgtop2.7
W: Unable to locate package libgtop2.7

> If you haven't got that one installed then maybe install it. If you
> already have it installed or if it didn't help then please let us know.

What repository do you propose this package is in?

It's quite obvious if you follow the bug history that the bug needs a
backport to Intrepid from a previous comment:

This bug was fixed in the package libgtop2 - 2.24.0-0ubuntu3

---------------
libgtop2 (2.24.0-0ubuntu3) jaunty; urgency=low

  * 50_linxu260_leak_fix.patch: Fix memory leak thanks to Brian Downing
    (LP: #307472).

 -- Kees Cook <email address hidden> Tue, 16 Dec 2008 09:56:24 -0800

I don't understand why you think a libgtop2.7 package is relevant to
this issue. Please explain.

b.

So I'm going to ask again, as I kill my multiload applet yet again, can we have this backported to intrepid, please?

If anyone is interested in seeing this fixed in Intrepid, please follow the SRU procedure:
https://wiki.ubuntu.com/StableReleaseUpdates

When the resident size of multiload-applet-2 reached 1.0 GiB on a 2 GiB memory system, all sorts of things started failing. This is on a desktop 8.10 lvm installation providing various services to other clients such as apache, svn etc.

* hard drives where on 100% iowait (swapping) leading to frozen-soft resetting entries in the system log
* my ssh connections became unresponsive after being idle for a few minutes
* the system could no longer be updated from repositories
* usb keyboards stopped working

dpkg -l lists that libgtop2-7 is of version 2.24.0-ubuntu2, which is the leaking version. A fix need to be submitted to 8.10 for this problem

It seems the only reason that the whole planet does not run into this is because they either reboot their systems often or do not have the system monitor active as an applet

Intrepid Ibex reached end-of-life on 30 April 2010 so I am closing the
report. The bug has been fixed in newer releases of Ubuntu.