memory leak in gnome-power-manager

[scottku]

==== 10.10 SRU ====
I'm requesting a backported fix for 10.10's gnome-power-manager based on the menu leak I found in 11.04. It's a simple one-line change, only affecting gnome-power-manager (rather than fixing root cause in libappindicator, because that potentially may adversely affect consumers that worked around it, though we know of none).

gnome-power-manager is seemingly the worst offender, so it gets special treatment. Test case right below. Watch memory use for a bit. It may go up for a few minutes, but then stabilizes.

Debdiff to follow, it's already been uploaded to maverick-proposed.
===================

TEST CASE: (at the beginning because it's a long post):
1. Monitor the output of the command for a few hours
  $ watch -n1 'grep heap -A11 /proc/$( pidof gnome-power-manager )/smaps'

VERIFICATION SUCCEEDED:
- Memory usage is stable over time

DESCRIPTION:
Binary package hint: gnome-power-manager

gnome-power-manager (2.30.0-0ubuntu1) seems to have a memory leak my machine running Lucid. I witnessed it using up to 120MB in the RES column according to "top". My machine is 64 bit and is connected to a APC uninterruptible power supply. I haven't yet tried unplugging it to see if the UPS is somehow related to this problem. Another person reported a similar problem in bug #196688 comment 25. Opening a new bug seemed like a good idea since that bug was fixed 2 years ago.

Here is some information for what gnome-power-manager looks like after running for a long period of time (from /proc/`pidof gnome-power-manager`/smaps):
0147b000-08810000 rw-p 00000000 00:00 0 [heap]
Size: 118356 kB
Rss: 118188 kB
Pss: 118188 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 118188 kB
Referenced: 118020 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB

I rebooted my machine and let it sit at the login screen. I logged via ssh and found that gnome-power-manager was using the following:
01f6e000-02075000 rw-p 00000000 00:00 0 [heap]
Size: 1052 kB
Rss: 944 kB
Pss: 944 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 944 kB
Referenced: 944 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB

I logged out of my ssh session and didn't touch the machine until 5 and 1/2 hours later---and I logged in again remotely with ssh to check on gnome-power-manager and found:
01f6e000-02e5d000 rw-p 00000000 00:00 0 [heap]
Size: 15292 kB
Rss: 15280 kB
Pss: 15280 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 15280 kB
Referenced: 15280 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: gnome-power-manager 2.30.0-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-21.32-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-21-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Fri Apr 23 22:23:32 2010
GnomeSessionIdleInhibited: No
GnomeSessionInhibitors: None
GnomeSessionSuspendInhibited: No
MachineType: DELL Inc. XPS 730X
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-21-generic root=UUID=e3f32a1f-7be3-45c9-9096-fa696ad50df3 ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-power-manager
dmi.bios.date: 07/16/2009
dmi.bios.vendor: DELL INC.
dmi.bios.version: 1.0.5
dmi.board.name: 0P270J
dmi.board.vendor: DELL Inc.
dmi.board.version: A00
dmi.chassis.type: 3
dmi.chassis.vendor: DELL Inc.
dmi.modalias: dmi:bvnDELLINC.:bvr1.0.5:bd07/16/2009:svnDELLInc.:pnXPS730X:pvr00:rvnDELLInc.:rn0P270J:rvrA00:cvnDELLInc.:ct3:cvr:
dmi.product.name: XPS 730X
dmi.product.version: 00
dmi.sys.vendor: DELL Inc.

[alexanghh (alexanghh)]

Hi,

I am also affected by this bug. Not sure what I should attach so I just copied the stats from top.

top - 23:10:09 up 7 days, 19:28, 2 users, load average: 1.65, 1.79, 1.86
Tasks: 236 total, 2 running, 234 sleeping, 0 stopped, 0 zombie
Cpu(s): 8.2%us, 18.8%sy, 0.5%ni, 72.2%id, 0.0%wa, 0.2%hi, 0.0%si, 0.0%st
Mem: 4059784k total, 3909296k used, 150488k free, 85432k buffers
Swap: 5116692k total, 809624k used, 4307068k free, 690984k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 2661 alex 20 0 1028m 523m 3376 S 0 13.2 2:06.77 gnome-power-man
31557 alex 25 5 1204m 397m 11m S 0 10.0 5:58.16 chrome
31572 alex 20 0 1213m 361m 11m S 0 9.1 7:54.32 chrome
31567 alex 20 0 1021m 230m 10m S 0 5.8 5:36.99 chrome
 1377 alex 20 0 981m 155m 24m S 3 3.9 437:33.93 firefox-bin
31562 alex 20 0 915m 130m 11m S 0 3.3 2:35.42 chrome
.....

[malp (ma-lp)]

I also think gnome-power-manager takes a bit much memory.

$ ps uwww 1793
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
userna 1793 0.0 4.3 190604 177600 ? S Apr30 1:28 gnome-power-manager

Mem: 167.7 MiB

$ uname -a
Linux ws7862 2.6.32-21-generic-pae #32-Ubuntu SMP Fri Apr 16 09:39:35 UTC 2010 i686 GNU/Linux

$ cat /proc/1793/smaps
08048000-08077000 r-xp 00000000 08:06 517232 /usr/bin/gnome-power-manager
Size: 188 kB
...
08077000-08078000 r--p 0002e000 08:06 517232 /usr/bin/gnome-power-manager
Size: 4 kB
...
08078000-08079000 rw-p 0002f000 08:06 517232 /usr/bin/gnome-power-manager
Size: 4 kB
...
09733000-138f1000 rw-p 00000000 00:00 0 [heap]
Size: 165624 kB
Rss: 165308 kB
Pss: 165308 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 165308 kB
Referenced: 118296 kB
Swap: 196 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
...

[Justin Lebar (jlebar)]

This bug rendered a friend's laptop basically unusable for a few weeks.

I can try running GPM on her machine under valgrind, if that would help.

[Justin Lebar (jlebar)]

Here's the (abbreviated) output from running Valgrind for a few minutes. Lots of leaks. Unfortunately gnome-power-manager doesn't have debug symbols.

Can we file upstream?

[Justin Lebar (jlebar)]

Filed: https://bugzilla.gnome.org/show_bug.cgi?id=618952

[Chris Coulson (chrisccoulson)]

The valgrind log isn't much use with all those missing symbols, and it doesn't show any big leaks that would explain your memory usage anyway

[Justin Lebar (jlebar)]

What about the blocks marked as possibly lost? There are a lot of them -- I had to cut 22k lines out of my log just so Launchpad wouldn't choke on the attachment. In my experience, Valgrind doesn't usually have so many false positives, even for that category.

I'll try and get symbols. In the meantime, it might be helpful if someone could confirm that a non-leaking instance of GPM doesn't cause Valgrind to find thousands of possibly-lost blocks.

[scottku (scottku)]

I installed some of the dbgsym packages and got a valgrind log. I ran the following for about 1.5 hours: valgrind --leak-check=full --log-file=gpm.log gnome-power-manager

Let me know if there is anything else I can do to help figure out this problem.

[Justin Lebar (jlebar)]

scottku,

It might be helpful to post a log with --show-reachable=yes so we can have a full(ish) accounting of where the program is using memory. Perhaps it's hanging onto some memory with a valid pointer that it should be freeing.

[scottku (scottku)]

Here is a valgrind log with --show-reachable=yes that I created by running gpm overnight (11 hours).

[Justin Lebar (jlebar)]

Richard Hughes identified in the Gnome bug that the problem is the app_indicator_set_menu() call, which is Ubuntu-specific.

Can we get an Ubuntu dev to look at this?

[Jason (beatme101)]

Is there a way to restart gnome-power-manager without restarting the computer? As this grows and grows in swap file usage, it becomes more cripping each time it randomly decides to load ALL of it's swap memory into system memory. For as long as this is happening, the system completely stops responding to input.

[Eloy Paris (peloy-chapus)]

On 05/27/2010 07:11 AM, Jason wrote:

> Is there a way to restart gnome-power-manager without restarting the
> computer? As this grows and grows in swap file usage, it becomes more
> cripping each time it randomly decides to load ALL of it's swap memory
> into system memory. For as long as this is happening, the system
> completely stops responding to input.

I sent the gnome-power-manager a HUP signal and that killed it. Then I
opened the Power Management control panel (System -> Preferences ->
Power Management) and that restarted gnome-power-manager. At least that
is what I remember I did yesterday when g-p-m was using like 200 megs of
RAM.

Cheers,

Eloy Paris.-

[Jason (beatme101)]

Thanks Eloy, great advice. Down from almost 400 MB, to 1.9 MB.

[Martin Pitt (pitti)]

Accepted indicator-application into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Paul Elliott (omahn)]

Can I just verify the test case, is to simply run the gnome-power-manager from -proposed for a while and check if the memory usage is reasonable?

[scottku (scottku)]

Paul: you are correct about the test case. Start gnome-power-manager, look at the memory usage, wait several hours (or a day), and look at the memory usage again. The buggy version will consume memory slowly (perhaps around 2MB per hour---which is approximately what I found in my original bug report above). I can't test it myself now, but will try to test it in a couple days.

[Christian Ziemann (zchristi)]

As for me, gnome-power-manager only seems to be leaking RAM while displaying the battery symbol in the panel (which is, while recharging the battery). However, the leak happens to be much more severe than scottku described, as it takes ~2 hours to eat 3GB of memory.

All the above concerns the buggy version, I am testing the fix from -proposed right now and will report.

[Derek (bugs-m8y)]

WRT displaying the battery symbol in comment #19

I've been up for 8 days, I noticed I was losing a lot of memory. Part of that was the ubunto one sync client (killed it).

400 megabytes of it though was the gnome-power-manager - and this on a desktop plugged into a UPS.

Killed that as well.

[scottku (scottku)]

It doesn't seem like the update fixes the problem for me. I enabled lucid-proposed in the update manager, updated my machine, and rebooted it. I logged in and gnome-power-manager was using:

01456000-0155f000 rw-p 00000000 00:00 0 [heap]
Size: 1060 kB
Rss: 1056 kB
Pss: 1056 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 1056 kB
Referenced: 1056 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB

I waited 2 hours (without doing anything on the machine) and found:

01456000-01a69000 rw-p 00000000 00:00 0 [heap]
Size: 6220 kB
Rss: 6096 kB
Pss: 6096 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 6096 kB
Referenced: 6096 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB

I can continue to let it run and report back if it is useful.

I do not see the rapid memory usage that Christian describes in comment #19. However, I do not have a battery icon displaying on the panel. I can try enabling it to see if I can reproduce the rapid memory usage if it would be helpful.

[Erich E. Hoover (ehoover)]

I'm seeing this issue and noticed that it appears to be "triggerable" by unplugging and plugging in the charger on my laptop. The interesting thing is that it triggers only when I plug the charger back in, and never appears to happen when I unplug it.

Convenient command-line for monitoring usage:
watch -n 0.1 'cat /proc/`ps ax|grep gnome-power-manager|grep -v grep|sed "s/\ *\([^? ]*\).*/\1/"`/smaps | grep "\[heap\]" -A 11'

[scottku (scottku)]

By using the script that Compholio provided in comment #22, I noticed that the Rss amount increases by about 20kB every 30 seconds on my machine. After watching it for several minutes, I'm pretty confident that the leak that I am seeing is caused by an event that happens every 30 seconds. 20kB per 30 seconds works out to roughly: 2,400kB every hour, 57,600kB per day, 403,200 kB per week, ~1,728,000 kB per month.

[scottku (scottku)]

Also, there are two reports about a problem similar to this one in bug #196688 in comments #25 and #26. There is also another report in bug #588383.

[Simon B (simonbrewerau)]

I used Compholio's script and it is showing 4kB every second (roughly). After three days I am at 670 MB. Possibly related to this is the battery in the laptop I am using does not hold any charge anymore. Maybe something is polling the battery?

[Simon B (simonbrewerau)]

One thing I forgot to mention is that I am running the 'proposed' package 'indicator-application 0.0.19-0ubuntu5' and it does not fix the problem.

[Justin Lebar (jlebar)]

In response to #25: I also observed this leak on a machine whose battery holds no charge. I haven't tried the proposed fix.

[Ben Gamari (bgamari)]

I too am running indicator-application 0.0.19-0ubuntu5 and yet am still experiencing leakage.

[Ben Gamari (bgamari)]

Just to note an interesting correlation, like #27, my specimen also has a battery which holds no charge.

[Simon B (simonbrewerau)]

I did a valgrind over about 8 hours(attached).

I removed my battery, restarted gnome-power-manager, and now the leak is gone.

[Jason (beatme101)]

In my case, although I experience the bug, it takes more time for the memory usage to expand, and it is on a PC with no battery (that the OS is aware of).

Just want to make it clear that it's not ONLY battery related.

[Simon B (simonbrewerau)]

Yes, in my case it is battery related. Jason, I wonder if you have a UPS, or some other power related device like that?

I did some more debugging. When I insert the battery, this subroutine is run continually:

Breakpoint 1, gpm_tray_icon_devices_changed_cb (engine=0x80a3238,
    icon=0x80d90e0) at gpm-tray-icon.c:338
338 in gpm-tray-icon.c

About once every second this routine is called and 4kB extra is used on the heap. I don't know enough about the code yet, but maybe the heap usage is never freed?

[cryptor3 (cryptor3)]

I'm experiencing this on my desktop. top says that virtual memory usage is stable at about 374m. The desktop doesn't have a UPS attached to it, however I did for some time have a wireless mouse/kb attached, and it was tracking that battery. I disconnected the mouse, because it is mostly a headless server.

[cryptor3 (cryptor3)]

oops. meant to say disconnected both mouse and kb.

[Jason (beatme101)]

Simon B, I do have a UPS but it's not connected in any way besides the power cable.

I have a wireless keyboard, but I've never seen anything that could detect the battery in it..

[Jean-Baptiste Lallement (jibel)]

I'm marking this report "verification-failed" regarding that 3 users reported that 0.0.19-0ubuntu5 in -proposed doesn't fix the leak.
I tried version 0.0.19-0ubuntu4 in lucid and compared with the version 0.0.19-0ubuntu5 in -proposed and didn't see any improvement regarding memory consumption between them, but the leak in both version is not as important as other users in this report (+4MB over 6hours)

[Simon B (simonbrewerau)]

I have some new information (however I do need some help from developers, please).

The chain of events is this:

1. upowerd - wakes while monitoring kernel drivers (sysfs/procfs). This can be very infrequent or very often depending on the h/w
2. upowerd - sends resulting message via dbus
3. gnome-power-manager - regenerates the app indicator menu every when it gets certain dbus messages, using up more heap memory each time.

How I verified this:

1. upowerd - sudo strace -p `pidof upowerd`
2. monitored dbus messages using
3. used gdb and set breakpoints (after installing -dbgsym packages)

I am still a little unsure that the events getting from upowerd to gnome-power-manager are the same; but I can tell they happen at the same frequency. Also if i remove my battery the events stop.

Summary: gnome-power-manager should be 'freeing' the menu, or not creating a new one every time. Many users will not see the problem because of a variable frequency of messages from upowerd (depending on their hardware).

[Ted Gould (ted)]

This is fixed in the upstream release 0.0.20 (current in the series is
0.0.21). Closing the upstream task. This fix has also been ported to
the current series, so I believe it is fixed in Maverick as well.

  affects indicator-application
  status fixreleased

[Simon B (simonbrewerau)]

I tried Maverick and the problem is not fixed in either Maverick or Lucid.

[Sebastien Bacher (seb128)]

could you give details on what usage numbers you watch and how?

[Pykler (hnassrat)]

I am running 10.10 and noticed the gnome-power-manager is abusively using ram. It was using 14% of 4GB with 19 days of uptime.

[Soos Gergely (sogerc1)]

I am using 10.10 too and had a contact failure in the cable between my laptop and my charger which seemd like the AC adapter was disconnected and connected back very rapidly and very frequently. I've fixed the cable but still, every time I unplug and plug back the AC adapter gnome-power-manager's RSS goes up (about 200k), also the RSS goes upwhen the battery finishes charging.
I'm not sure what the normal memory usage of gnome-power-manager should be but before I fixed the cable gnome-power-manager consumed all my 4GB RAM in under 3 hours which was horrible. My workaround is that I restart gnome-power-manager every 15 minutes using a cronjob. The script is very simple, I copy here in case anyone needs a workaround until the bug is fixed:

--- CUT HERE ---
#!/bin/sh

export DISPLAY=:0
killall -q gnome-power-manager
gnome-power-manager >/dev/null 2>&1 &
--- CUT HERE ---

Save the text between the CUT HERE markers into a file, for example /usr/local/bin/gpmrestart, then type into a terminal
crontab -e
and enter this line:
*/15 * * * * /usr/local/bin/gpmrestart

This workaround seems not to have any sideeffect (except that the battery icon flickers every 15 minutes), I've been using it for several months.

One detail I forgot to mention: I have uninstalled indicator-applet right after I installed/upgraded my linux (because I see no reason to use it).

[jcapinc (jeffs-linux)]

I would just like to confirm, gnome power manager was using over 400 mb of ram after over 12 hours of computer not being used.

[Bruce Dudek (bd4465)]

I just had this happen to me today after 24 hours of uptime. It was about 300M of memory. I am running 10.10 - 2.6.35-23-generic #41-Ubuntu SMP

[Aaron Haviland (aaron-haviland)]

Not a fix, but a workaround: Each time app_indicator_set_menu() is called, we leak by 200k. so, I reduced the number of times it gets called. (Currently called any time a device is updated, which seems to happen every 30 seconds. Devices are updated even if nothing has changed.)

I'm rather novice, so I've probably fudged something else up by doing this. It works for me (desktop, wireless mouse being the only battery indicator I have) I couldn't make heads or tails of the actual leak itself, though.

The attached patch has been applied to package, and uploaded to my ppa:aaron-haviland/ppa for Maverick.
I've also applied it to the Lucid package and uploaded, but I don't have a lucid system to test it on.

After running for 2 hours, according to /proc/pid/smaps Rss has only increased by 240kB

[Aaron Haviland (aaron-haviland)]

FYI, 4 days later, and still no major leakage.

[FMaz (fmaz008)]

Why app_indicator_set_menu() makes a 200k leak ? Would it be possible to sanitize that function/method in order to avoid making it leak 200K ?

[Wirawan Purwanto (wirawan0)]

I'm new to this bug. But I have noticed in my case that over time, the g-p-m memory usage grows steadily to many tens of MB. I don't remember a case where g-p-m grows to 500 MB. I just restarted and it used ~8.5MB. I'm using this on a laptop which is running of A/C most of the time but sometimes it runs on battery. And it is suspended and resume day after day (and brought with me to home and office); and the OS/desktop is not typically restarted after 1 month or more. After ~13 days it grew to something like 30 MB. So not as fast as the problem reported here, but still bad. I made g-p-m not show anything except when running on battery and when battery is actually charging.

If this bug is different, let me know if there's already a bug page for this.

[Tim Towers (tim-lorien)]

I am seeing this behavior on a patched Ubuntu 10.10 desktop (no battery)
gnome-power-manager was up to about 400\b and indicator-applet is up to 122Mb in about 30 days on a lightly used system

[Will Daniels (wdaniels)]

This is either not fixed or it's back!

I had to kill gnome-power-manager on my maverick desktop yesterday (all updates applied). It was using just under 500MB of 2GB total. The machine is heavily used with uptime 34 days.

Package: gnome-power-manager
Architecture: amd64
Version: 2.32.0-0ubuntu1

I've not seen any such problem with indicator-applet however.

[Eloy Paris (peloy-chapus)]

On 01/16/2011 05:30 PM, Will Daniels wrote:

> This is either not fixed or it's back!

I don't think it has ever been fixed. If that's the case, and if this is
an Ubuntu-specific problem as I think upstream seems to think, it is a
shame that two Ubuntu releases after the problem was introduced the
problem still exists.

Cheers,

Eloy Paris.-

>
> I had to kill gnome-power-manager on my maverick desktop yesterday (all
> updates applied). It was using just under 500MB of 2GB total. The
> machine is heavily used with uptime 34 days.
>
> Package: gnome-power-manager
> Architecture: amd64
> Version: 2.32.0-0ubuntu1
>
> I've not seen any such problem with indicator-applet however.

[Will Daniels (wdaniels)]

Using the watch/grep command, it currently seems to be leaking about 16kB every 30 seconds on my system right now (no battery or panel indicator), although 500MB over 33 days would suggest a slower rate over time. I can just remove it of course, but there is definitely still a problem here.

[Chad Wagner (chad-wagner)]

For me gnome-power-manager has approximately a 170KB leak every 10 minutes on Ubuntu 10.04 amd64, and indicator-applet has about a 16KB leak every 10 minutes. Using atop and looking at the history makes it a bit obvious. All patches applied, still broken and leaking memory. :( This is after all updates applied and a clean boot.

[Jimmy Merrild Krag (beruic)]

Could this be related: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/684599

[Simon B (simonbrewerau)]

Quite a while ago I made an simple example that leaks memory via app-indicator.

https://bugs.launchpad.net/ubuntu/+source/indicator-application/+bug/569273/comments/80

If someone has the time, they can run this example and should be able to debug the leak.

[Max Chen (maxchen)]

yeah, memory leak in gnome-power-manager and gnome-system-monitor, these 2 will eat almost 100MiB each for running several days. waiting for a fix.

[Karl Lattimer (karl-qdh)]

Can you tell me if you have menu icons turned on? I've discovered other leaks associated with that feature.

We don't intend to *ship* it that way, but lots of legacy configuration has remained static.

[Gergely Csépány (cheoppy)]

I have menu icons turned on. And after 45h uptime, gnome-power-manager eats 96.8MiBs of memory.

[Jarmo Ilonen (trewas)]

I am not sure if yet another "me too" helps anything, but I am seeing this problem on a ubuntu 10.10 x86 desktop. Despite being a desktop, gnome-power-manager sees some action because it warns when the mouse (logitech mx1000) battery gets low.

On this computer gnome-power-manager now takes 102636kB (Size from /proc/pid/smaps) after five days of uptime. The computer is always on and after about a month gnome-power-manager has to be killed and restarted because the overall performance starts to degrade caused by wasted memory. Gnome-power-manager does not seem to ever get swapped out and stays in RAM, so it must access all that allocated memory quite often.

I am not sure which menu icons matter, but for example gedit does not show icons in file/edit/etc menus, but gnome-panel shows them in applications/places/system menus. There is no interface tab in gnome-appearance-properties to change the setting.

BTW, why is this bug hidden when searching "gnome-power-manager memory leak" in bugs.ubuntu.com? This page is the first hit in google with the same search string.

[Aaron Clark (aaronwclark)]

I am seeing the same thing with Gnome-Power-Manager, Opera 11.01 and touchthesky 1.14 (a weather monitoring widget installed with Opera). All three slowly increase mem usage until all 6 gig on this machine are consumed. Ubuntu 10.04 64.
Usually can't stay up for more than 3 to 5 days without restarting those apps to get the memory back.

The interesting thing is that I have a very nearly identical machine (both desktops) in my office. same Intel Q6600 proc - similar but not identical Asus mbs 8 Gig on office machine. ATI graphics on home, Nvidia on office. Same wireless mouse & keyboard.

All the same major Apps installed on both machines - both machines kept updated - On the office machine power manager stays at a consistent 1.9 meg, Opera between 200 & 400 meg depending on how many tabs I leave open - Touchthesky also doesn't change the memory used with time.

If I can find the time I will generate a list of installed software for each & see if anything stands out.

[Ben Gamari (bgamari)]

On Tue, Feb 1, 2011 at 8:35 PM, Aaron Clark <email address hidden> wrote:
> I am seeing the same thing with Gnome-Power-Manager, Opera 11.01 and touchthesky 1.14 (a weather monitoring widget installed with Opera).  All three slowly increase mem usage until all 6 gig on this machine are consumed.  Ubuntu 10.04 64.
> Usually can't stay up for more than 3 to 5 days without restarting those apps to get the memory back.

Could you run this software in valgrind? This could provide some useful hints.

[Aaron Clark (aaronwclark)]

>Could you run this software in valgrind? This could provide some useful hints.

I am installing valgrind now - Will try to run it as soon as I get time in the next few days.

[Aaron Roydhouse (aaron-roydhouse)]

Just freshly installed Maverick 10.10 64bit on a Lenovo X301 and after three days gnome-power-manager is at 193MB. Doesn't seem like the Maverick fix worked.

0107d000-0ca34000 rw-p 00000000 00:00 0 [heap]
Size: 190172 kB
Rss: 190072 kB
Pss: 190072 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 190072 kB
Referenced: 180048 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB

[Michael Terry (mterry)]

I have looked into this and have a fix and an explanation. First, please be mindful of this bugs many subscribers before following up with non-technical comments.

The bug appears to be in libappindicator itself. The call to app_indicator_set_menu leaks the old menu every time a new menu is passed in. It should instead sink any floating ref on the old menu than just unconditionally adding a new reference (see [1] for technical details on what the heck that means).

There's actually two possible ways to fix this. (A) change libappindicator to sink the ref, which would arguably be an API change. Or (B) change gnome-power-manager to manually unref the menu after passing it to libappindicator. I'm going with (A) for now and have filed a patch against libappindicator [2].

I suspect that even if method (A) is approved and merged for natty, method (B) is most appropriate for any possible SRUs.

[1] http://library.gnome.org/devel/gobject/stable/gobject-The-Base-Object-Type.html#floating-ref
[2] https://code.launchpad.net/~mterry/libappindicator/fix-menu-leak/+merge/53247

[Martin Pitt (pitti)]

Accepted gnome-power-manager into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Moritz Naumann (mnaumann)]

Indeed 2.32.0-0ubuntu1.1 uses much less RAM. I'm still up to 60160 kbytes RSS after 4 days (which still seems too much), but this is nowhere close to the 250 MB and more it used to use.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-power-manager - 2.32.0-0ubuntu1.1

---------------
gnome-power-manager (2.32.0-0ubuntu1.1) maverick-proposed; urgency=low

  * debian/patches/12-add-appindicators.patch:
    - Fix leak by working around a libappindicator bug. LP: #569273
 -- Michael Terry <email address hidden> Wed, 16 Mar 2011 15:55:26 -0400

[demilord (demilord)]

~/.xsession-errors keeps getting filled now with these messages, running 10.10 maverick meerkat.

Is there a way to get rid of these messages.. because it keeps going on and on.. And can grow till tens if not hundreds of mb's which is a bit much for a log file

Gtk-WARNING **: A floating object was finalized. This means that someone
called g_object_unref() on an object that had only a floating
reference; the initial floating reference is not owned by anyone
and must be removed with g_object_ref_sink().

[demilord (demilord)]

Is there any news with the regression which affects Maverick Meerkat.. It keeps spitting out messages..

(gnome-power-manager:<number>): Gtk-WARNING **: A floating object was finalized. This means that someone
called g_object_unref() on an object that had only a floating
reference; the initial floating reference is not owned by anyone
and must be removed with g_object_ref_sink().

would be nice to see it fixed someway.. so it doesn't fill the home partition and makes .xsession-errors more clean for other more important debug issues...

[Max Chen (maxchen)]

Ubuntu 10.04 X64, updated , but the gnome-power-manager still growing it memory consumed.

[Yura Pakhuchiy (yura-p)]

Why won`t fix for lucid? Please backport to lucid also

[Joe le Kiffeur (joelekiffeur)]

It's a very critical problem, because the whole system is slowing down.
Please patch this.

[Vadim Peretokin (vperetokin)]

Are you going to make a patch?
On Mar 1, 2012 1:56 AM, "Joe le Kiffeur" <email address hidden> wrote:

> It's a very critical problem, because the whole system is slowing down.
> Please patch this.
>
> ** Changed in: gnome-power-manager (Ubuntu Lucid)
> Assignee: (unassigned) => Joe le Kiffeur (joelekiffeur)
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (625852).
> https://bugs.launchpad.net/bugs/569273
>
> Title:
> memory leak in gnome-power-manager
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/indicator-application/+bug/569273/+subscriptions
>

[JC Hulce (soaringsky)]

This bug affects Ubuntu 10.10, Maverick Meerkat. Maverick has reached end-of-life and is no longer supported, so I am closing the bugtask for Maverick. Please upgrade to a newer version of Ubuntu.
More information here: https://lists.ubuntu.com/archives/ubuntu-announce/2012-April/000158.html

[Michael Terry (mterry)]

I've uploaded the fix we used for 10.10 to lucid-proposed too. Same SRU justifications apply.

[Adam Conrad (adconrad)]

Hello scottku, or anyone else affected,

Accepted gnome-power-manager into lucid-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gnome-power-manager/2.30.0-0ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

The fix for this bug has been awaiting testing feedback in the -proposed repository for lucid for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository.

[Gennadiy (gen-pover)]

cnc

[Bryan Quigley (bryanquigley)]

Ubuntu Lucid is no longer supported on the desktop. Because of that should we drop the SRU for gnome-power-manager?