multiload-applet-2 leaks memory

Bug #307472 reported by Brian Downing on 2008-12-12
40
This bug affects 2 people
Affects Status Importance Assigned to Milestone
libgtop
Fix Released
Medium
libgtop2 (Ubuntu)
Medium
Ubuntu Desktop Bugs
Intrepid
Undecided
Unassigned
Jaunty
Medium
Ubuntu Desktop Bugs

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

Related branches

Pedro Villavicencio (pedro) wrote :

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.

Changed in gnome-applets:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Incomplete
Brian Downing (bd-launchpad) wrote :

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.

Brian Downing (bd-launchpad) wrote :

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

Brian Downing (bd-launchpad) wrote :

:; /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?

Brian Downing (bd-launchpad) wrote :

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.

Tom (tom6) wrote :

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 :)

Brian Downing (bd-launchpad) wrote :

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.

Brian Downing (bd-launchpad) wrote :

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.

Brian Downing (bd-launchpad) wrote :

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

Brian Downing (bd-launchpad) wrote :

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.

Sebastien Bacher (seb128) wrote :

thank you for your work there

Changed in libgtop2:
status: Incomplete → Confirmed
Launchpad Janitor (janitor) wrote :

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

Changed in libgtop2:
status: Confirmed → Fix Released

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
>

Changed in libgtop:
status: Unknown → Fix Released

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

Tom (tom6) wrote :

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 :)

ilinux (bnufl66) wrote :

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?

Kees Cook (kees) wrote :

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

Changed in libgtop2 (Ubuntu Intrepid):
status: New → Confirmed
Harald Rudell (harald-rudell) wrote :

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

Changed in libgtop2 (Ubuntu Intrepid):
assignee: nobody → desktop-bugs
Alex Valavanis (valavanisalex) wrote :

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.

Changed in libgtop2 (Ubuntu Intrepid):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
status: Confirmed → Invalid
Changed in libgtop:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.