Memory Leak in Unity (Compiz)

Bug #1061792 reported by GonzO
56
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Unity
Expired
High
Unassigned
unity (Ubuntu)
Expired
High
Unassigned

Bug Description

There seems to be a memory leak in Unity that comes with use (not age).

Hardware: ThinkPad W510 (nVidia Quadro FX 880M, driver 304.51), Core2-Duo-based desktop with nVidia 560Ti (same driver)

Software: Quantal Beta, up-to-the-moment updates, both 64- and 32-bit (one of each).

*Note: I can *not* test with nouveau. Not only is it completely unsuitable for laptops due to terrible power management, but neither computer will boot with it - I get the PFIFO stuff, even though the -16 kernel was supposed to fix that.

Steps to reproduce:

1) Log into Unity and launch System Monitor (gnome-system-monitor). Set to view "all processes" and organize by the "memory" column. Take note of the amount of RAM taken by the Compiz and Xorg processes.

2) Open a bunch of programs. I use: Nautilus, Gnome-Terminal, Chrome, Banshee, EasyTag, EasyMP3Gain, Empathy, Eclipse, and Rhythmbox.

3) Close all of the programs except gnome-system-monitor. Note the increase in RAM the Compiz and Xorg processes take.

4) Repeat steps 3-4. Memory on each process steadily rises.

It isn't by a lot, but it creates an environment wherein the longer one uses one's Unity session, the less free RAM one has to work with (as neither process ever seems to give up any of its RAM, ever, not even after 10 hours of use).

I don't seem to have any stability or performance issues stemming from this.

ALSO: Opening the dash at all raises the RAM usage by a LOT, and subsequent openings of the dash (poking around, clicking on new buttons that reveal icons I haven't seen before, etc) also grows the process's RAM. By a LOT on the first run, but by a noticeable amount on later runs.

*I* think this is a pretty high-priority issue, but as the RAM use and growth isn't all THAT large (~0.5/1 MiB every time steps 2-3 are repeated), I could understand if it weren't marked critical... but I think any leak is critical, so there's my bias.

STEALTH EDIT: I want to point out that just leaving the system logged in does not cause Unity *or* Xorg to use more RAM over time. Not even with the indicator-multiload running.

STEALTH EDIT #2: All lenses and scopes except the Application lens have been uninstalled, and do not factor into this. So I'm pretty sure we don't have a runaway call in any indexer or anything like it.
---
ApportVersion: 2.6.1-0ubuntu1
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
DistroRelease: Ubuntu 12.10
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Beta amd64 (20120926)
NonfreeKernelModules: nvidia
Package: unity 6.8.0-0ubuntu1
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 3.5.0-17.26-generic 3.5.5
Tags: quantal third-party-packages
Uname: Linux 3.5.0-17-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

GonzO (gonzo)
description: updated
GonzO (gonzo)
description: updated
GonzO (gonzo)
description: updated
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

The Xorg leaks are very likely the X resource leaks described in bug 1050610 and bug 1057263. Those will bloat X rather than bloating the offending process gtk-window-decorator.

The issue with opening the dash using lots of memory is bug 982434.

If you think you have a new leak that is none of the above, please run this command so we know what package versions are affected:
    apport-collect 1061792

Changed in unity:
status: New → Incomplete
Changed in unity (Ubuntu):
status: New → Incomplete
Revision history for this message
GonzO (gonzo) wrote : Dependencies.txt

apport information

tags: added: apport-collected quantal third-party-packages
description: updated
Revision history for this message
GonzO (gonzo) wrote : GconfCompiz.txt

apport information

Revision history for this message
GonzO (gonzo) wrote : ProcEnviron.txt

apport information

Revision history for this message
GonzO (gonzo) wrote :

"The Xorg leaks are very likely the X resource leaks described in bug
1050610
and bug 1057263. Those will bloat X rather than bloating the
offending process gtk-window-decorator."

I'm using the versions of Compiz that the fix for both were supposed to have been released in.

Also, X is bloating, yes -- but much slower than the Compiz proc. It is always smaller than the Compiz proc.

"The issue with opening the dash using lots of memory is bug 982434."

...that's also my defect. :-)

Though this isn't complaining about that - the mem usage in the Dash is high, yes, but eventually *stops* once you've seen everything you can possibly see in there. (The shopping icons throw a monkey wrench into that - whenever those options change up, the memory usage increases, so there is a chance that the shopping lens can create an environment wherein Unity will expand indefinitely. But I uninstalled that lens anyway. :-))

"If you think you have a new leak that is none of the above, please run this command so we know what package versions are affected:
    apport-collect 1061792"

Oh my. That is *slick*. Incoming.

Changed in unity:
status: Incomplete → New
Changed in unity (Ubuntu):
status: Incomplete → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in unity (Ubuntu):
status: New → Confirmed
Revision history for this message
autra (autra) wrote :

Same here. Compiz uses 500mb of memory. Xorg 177m
Also cpu usage of Compiz is quite high (around 10% all the time)

Revision history for this message
Arie Skliarouk (skliarie) wrote :

Same here: Lenovo ThinkPad t61p, (NVIDIA Corporation G84GLM [Quadro FX 570M] (rev a1))
Ubuntu 13.04 (Raring) amd64.

Takes about a day of normal work to silently fill 2GB of swap. After that the system quickly enters into endless thrashing.

James Ramsay (f-jack)
Changed in unity:
status: New → Confirmed
Revision history for this message
James Ramsay (f-jack) wrote :

I was able to get it to lock up in thirty minutes just opening and closing programs constantly compiz used up all of swap and most of my ram

Stephen M. Webb (bregma)
Changed in unity (Ubuntu):
importance: Undecided → High
Changed in unity:
importance: Undecided → High
status: Confirmed → Triaged
Changed in unity (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Vadim Peretokin (vperetokin) wrote :

I left the computer on overnight, and without any use compiz racked up 12gigs of memory: http://i.imgur.com/bz1Lk0R.png

Ubuntu 13.10 64bit, Nvidia 319.60, GeForce GTX 650 Ti.

Revision history for this message
Andrea Azzarone (azzar1) wrote :

@Gonzo, is this still a problem?

Changed in unity:
status: Triaged → Incomplete
Changed in unity (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
positivek (anonyhole) wrote :

Yes, still a problem in Ubuntu 14.04.1 LTS trusty.
gtk-window-decorator racks up memory use over time.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for unity (Ubuntu) because there has been no activity for 60 days.]

Changed in unity (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for Unity because there has been no activity for 60 days.]

Changed in unity:
status: Incomplete → Expired
Revision history for this message
Stephen M. Webb (bregma) wrote :

Just a note: gtk-window-decorator is incompatible with Unity (they can not be run at the same time) and it's unlikely that a leak in gtk-window-decorator is relaed to a problem in Unity. If there is a problem with gtk-window-decorator it needs to be reported against the Compiz project not as a comment against a bug in the Unity project.

Revision history for this message
Eero-t-tamminen (eero-t-tamminen) wrote :

Could this be related to 1065657? (Which is Compiz leak separate from the gtk-window-decorator issue)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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