memory leaking in compiz

Bug #758248 reported by Kees Cook
230
This bug affects 45 people
Affects Status Importance Assigned to Milestone
Nux
Fix Released
Medium
Unassigned
Unity
Fix Released
Medium
Jay Taoko
compiz (Ubuntu)
Invalid
Medium
Unassigned
Natty
Invalid
Undecided
Unassigned
nux (Ubuntu)
Fix Released
Medium
Unassigned
Natty
Fix Released
Undecided
Unassigned
unity (Ubuntu)
Fix Released
Undecided
Unassigned
Natty
Won't Fix
Undecided
Unassigned

Bug Description

========================
Fixed in natty-proposed

Test case:
1. install nux version 0.9.48-0ubuntu1.1 and restart your session
2. check the current memory of nux with your favorite tool
3. trigger <what made the mem leak>
4. check again the memory taken by nux (compiz process) and see that it didn't increase
========================

Binary package hint: compiz

I noticed today that compiz had hit 4G of memory over 2 days. I updated to the latest of everything today and rebooted, after following a modified version of https://wiki.ubuntu.com/X/DebuggingWithValgrind and https://wiki.ubuntu.com/Valgrind against /usr/bin/compiz, and am attaching the valgrind logs now. Summary shows:

==7291== LEAK SUMMARY:
==7291== definitely lost: 148,549 bytes in 1,898 blocks
==7291== indirectly lost: 2,488,656 bytes in 14,344 blocks
==7291== possibly lost: 1,527,217 bytes in 4,375 blocks
==7291== still reachable: 28,831,515 bytes in 63,181 blocks
==7291== suppressed: 0 bytes in 0 blocks
==7291== Reachable blocks (those to which a pointer was found) are not shown.
==7291== To see them, rerun with: --leak-check=full --show-reachable=yes

With the most extreme:

==7291== 404,504 (4,320 direct, 400,184 indirect) bytes in 54 blocks are definitely lost in loss record 24,631 of 24,640
...
==7291== by 0x7327398: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.2800.5)
...
==7291== by 0x172A899E: gdk_pixbuf_new_from_data (in /usr/lib/libgdk_pixbuf-2.0.so.0.2300.3)
...
==7291== by 0x154DAD18: nux::UXTheme::Load2DTextureFile(char const*) (in /usr/lib/libnux-0.9.so.0.938.4)

$ bzcat /tmp/compiz-valgrind.log.bz2 | grep '== [^ ]' | grep 'definitely lost' | wc -l
1675

This is from running compiz (with Unity) for about 5 minutes.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: compiz 1:0.9.4+bzr20110411-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,compiztoolbox,decor,move,regex,resize,gnomecompat,mousepoll,snap,place,wall,imgpng,resizeinfo,vpswitch,animation,unitymtgrabhandles,expo,session,ezoom,workarounds,staticswitcher,fade,scale,unityshell]
CompositorRunning: compiz
DRM.card0.DVI.D.1:
 status: connected
 enabled: enabled
 dpms: On
 modes: 1920x1200 1600x1200 1280x1024 1280x1024 1152x864 1024x768 1024x768 800x600 800x600 640x480 640x480 720x400
 edid-base64: AP///////wAQrBXwTDZDNCEUAQOANCB47h7Frk80sSYOUFSlSwCBgKlA0QBxTwEBAQEBAQEBKDyAoHCwI0AwIDYABkQhAAAaAAAA/wBDNTkyTTA4QzRDNkwKAAAA/ABERUxMIFUyNDEwCiAgAAAA/QA4TB5REQAKICAgICAgAGw=
DRM.card0.VGA.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
Date: Mon Apr 11 17:48:36 2011
DistroCodename: natty
DistroVariant: ubuntu
GraphicsCard:
 Intel Corporation 82Q35 Express Integrated Graphics Controller [8086:29b2] (rev 02) (prog-if 00 [VGA controller])
   Subsystem: Intel Corporation Device [8086:4f4a]
   Subsystem: Intel Corporation Device [8086:4f4a]
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-2.6.38-8-generic root=/dev/mapper/systemvg-root2lv ro quiet splash vt.handoff=7
ProcVersionSignature_: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Renderer: Unknown
SourcePackage: compiz
UpgradeStatus: Upgraded to natty on 2006-11-27 (1596 days ago)
XorgConf:
 Section "ServerFlags"
  Option "DontZap" "False"
 EndSection
dmi.bios.date: 09/22/2008
dmi.bios.vendor: Intel Corp.
dmi.bios.version: JOQ3510J.86A.0954.2008.0922.2331
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: DQ35JO
dmi.board.vendor: Intel Corporation
dmi.board.version: AAD82085-800
dmi.chassis.type: 3
dmi.modalias: dmi:bvnIntelCorp.:bvrJOQ3510J.86A.0954.2008.0922.2331:bd09/22/2008:svn:pn:pvr:rvnIntelCorporation:rnDQ35JO:rvrAAD82085-800:cvn:ct3:cvr:
version.compiz: compiz 1:0.9.4+bzr20110411-0ubuntu1
version.ia32-libs: ia32-libs 20090808ubuntu12
version.libdrm2: libdrm2 2.4.23-1ubuntu6
version.libgl1-mesa-dri: libgl1-mesa-dri 7.10.2-0ubuntu1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.10.2-0ubuntu1
version.xserver-xorg: xserver-xorg 1:7.6+4ubuntu3
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.0-0ubuntu4
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.14.0-4ubuntu6
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu7

Revision history for this message
Kees Cook (kees) wrote :
Revision history for this message
Kees Cook (kees) wrote :
Revision history for this message
Kees Cook (kees) wrote :

It's not clear if this is related to 751409, but my earlier leaks sure seemed that bad.

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

Worth at least to look at the nux one:
nux::UXTheme::Load2DTextureFile(char const*) (in /usr/lib/libnux-0.9.so.0.938.4)

Changed in nux:
status: New → Incomplete
status: Incomplete → Triaged
Changed in compiz (Ubuntu):
status: New → Triaged
Changed in nux:
importance: Undecided → High
Changed in unity:
importance: Undecided → High
status: New → Triaged
Changed in nux (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in compiz (Ubuntu):
importance: Undecided → High
Changed in unity:
assignee: nobody → Jay Taoko (jaytaoko)
milestone: none → 3.8.8
Revision history for this message
Robert Hooker (sarvatt) wrote :

According to bug #760161 this appears to also be happening in a classic session

Changed in unity:
milestone: 3.8.8 → 3.8.10
Changed in unity:
milestone: 3.8.10 → 3.8.12
Revision history for this message
David Barth (dbarth) wrote :

@Jay: could you give us your feedback about Didier's comment, ie investigate nux::UXTheme::Load2DTextureFile(char const*) (in /usr/lib/libnux-0.9.so.0.938.4)

Changed in unity:
importance: High → Medium
Changed in nux:
importance: High → Medium
Changed in compiz (Ubuntu):
importance: High → Medium
Changed in nux (Ubuntu):
importance: High → Medium
Changed in unity:
milestone: 3.8.12 → 3.8.14
Revision history for this message
Vadim Peretokin (vperetokin) wrote :

Confirmed here on nVidia.

Revision history for this message
Peter Petersson (petersson-peter) wrote :

Also on nVidia
Compiz 1.4GiB after one hour of work
Natty
kernel 2.6.38-9-generic
Memory 3,8GiB

Revision history for this message
Alf (antonio-floresta) wrote :

Confirmed here on nVidia (Lenovo T61) and Intel (Lenovo ThinkCentre 8810-AA5).
Steps to reproduce:
* minimize and restore a window (gnome-terminal, for example).
* drag a window until touching the gnome-panel on the top.
* maximize and restore a window.

Revision history for this message
Omer Akram (om26er) wrote : Re: [Bug 758248] Re: memory leaking in compiz
Download full text (5.2 KiB)

alf, with the steps you provided i cannot reproduce any memory leak
here on intel gpu. I might try it on nvidia when i have the access to
it.

On Mon, May 16, 2011 at 5:57 PM, Alf <email address hidden> wrote:
> Confirmed here on nVidia (Lenovo T61) and Intel (Lenovo ThinkCentre 8810-AA5).
> Steps to reproduce:
> * minimize and restore a window (gnome-terminal, for example).
> * drag a window until touching the gnome-panel on the top.
> * maximize and restore a window.
>
> --
> You received this bug notification because you are subscribed to unity.
> https://bugs.launchpad.net/bugs/758248
>
> Title:
>  memory leaking in compiz
>
> Status in Nux:
>  Triaged
> Status in Unity:
>  Triaged
> Status in “compiz” package in Ubuntu:
>  Triaged
> Status in “nux” package in Ubuntu:
>  Triaged
>
> Bug description:
>  Binary package hint: compiz
>
>  I noticed today that compiz had hit 4G of memory over 2 days. I
>  updated to the latest of everything today and rebooted, after
>  following a modified version of
>  https://wiki.ubuntu.com/X/DebuggingWithValgrind and
>  https://wiki.ubuntu.com/Valgrind against /usr/bin/compiz, and am
>  attaching the valgrind logs now. Summary shows:
>
>  ==7291== LEAK SUMMARY:
>  ==7291==    definitely lost: 148,549 bytes in 1,898 blocks
>  ==7291==    indirectly lost: 2,488,656 bytes in 14,344 blocks
>  ==7291==      possibly lost: 1,527,217 bytes in 4,375 blocks
>  ==7291==    still reachable: 28,831,515 bytes in 63,181 blocks
>  ==7291==         suppressed: 0 bytes in 0 blocks
>  ==7291== Reachable blocks (those to which a pointer was found) are not shown.
>  ==7291== To see them, rerun with: --leak-check=full --show-reachable=yes
>
>  With the most extreme:
>
>  ==7291== 404,504 (4,320 direct, 400,184 indirect) bytes in 54 blocks are definitely lost in loss record 24,631 of 24,640
>  ...
>  ==7291==    by 0x7327398: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.2800.5)
>  ...
>  ==7291==    by 0x172A899E: gdk_pixbuf_new_from_data (in /usr/lib/libgdk_pixbuf-2.0.so.0.2300.3)
>  ...
>  ==7291==    by 0x154DAD18: nux::UXTheme::Load2DTextureFile(char const*) (in /usr/lib/libnux-0.9.so.0.938.4)
>
>  $ bzcat /tmp/compiz-valgrind.log.bz2 | grep '== [^ ]' | grep 'definitely lost' | wc -l
>  1675
>
>  This is from running compiz (with Unity) for about 5 minutes.
>
>  ProblemType: Bug
>  DistroRelease: Ubuntu 11.04
>  Package: compiz 1:0.9.4+bzr20110411-0ubuntu1
>  ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
>  Uname: Linux 2.6.38-8-generic x86_64
>  Architecture: amd64
>  CompizPlugins: [core,bailer,detection,composite,opengl,compiztoolbox,decor,move,regex,resize,gnomecompat,mousepoll,snap,place,wall,imgpng,resizeinfo,vpswitch,animation,unitymtgrabhandles,expo,session,ezoom,workarounds,staticswitcher,fade,scale,unityshell]
>  CompositorRunning: compiz
>  DRM.card0.DVI.D.1:
>   status: connected
>   enabled: enabled
>   dpms: On
>   modes: 1920x1200 1600x1200 1280x1024 1280x1024 1152x864 1024x768 1024x768 800x600 800x600 640x480 640x480 720x400
>   edid-base64: AP///////wAQrBXwTDZDNCEUAQOANCB47h7Frk80sSYOUFSlSwCBgKlA0QBxTwEBAQEBAQEBKDyAoHCwI0AwIDYABkQhAAAaAAAA/wBDNTkyTTA4QzRDNkwKAAAA...

Read more...

Revision history for this message
Nicholas Shatokhin (robotex) wrote :

At office It works good with Intel and AMD cards, but on my laptop with GeForce 8600M GS it is leaking.

Revision history for this message
kenden (kenden) wrote :

I could reproduce with Natty running in VirtualBox
(with host computer using ATI Radeon HD 4550)
$ uname -a
Linux qUbVM 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

I followed Peter's steps at comment #8.
Compiz started at 44.2 MiB (FYI: 4 times as much as Ubuntu Classic, 11.4 MiB)
and after 5-10 minutes, it was using 49.3 MiB

Revision history for this message
Alf (antonio-floresta) wrote :

On my Lenovo desktop (ThinkCentre 8810-AA5) with an Intel graphics the leak problem only occurs when using Unity. If I select the Ubuntu Classic (compiz without the Unity) the compiz process does not seems to leak any memory.
So the problem seems to be more related to the Unity, not to compiz.

Revision history for this message
Krister Swenson (thekswenson) wrote :

This is a friendly question...
   why is the importance of this bug "medium"?
Compiz uses half my memory. After using my computer for a couple hour I have to reboot.
On my other old machine, the computer become unusable after a shorter amount of time.

Revision history for this message
Cliff Stewart (cliffstewart) wrote :

I have the compiz memory leak from startup on my Acer TM6292 (Intel GPU) running Unity.

Sat May 21 13:57:41 SAST 2011
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
cliff 1550 7.8 3.0 253092 62360 ? Rl 13:38 1:28 compiz

Sat May 21 14:04:45 SAST 2011
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
cliff 1550 7.7 3.4 262316 70220 ? Sl 13:38 2:00 compiz

I left my pc on overnight and compiz was using 1.1GB!!

If you would like to use my system to troubleshoot that will be fine.

Revision history for this message
Cliff Stewart (cliffstewart) wrote :

In ubuntu classic there is no leak. It only occurs when running Unity.

Revision history for this message
Cliff Stewart (cliffstewart) wrote :

I solved my issue. An applet called indicator-multiload was the culprit.

Revision history for this message
Reinhard Tartler (siretart) wrote :

On Sat, May 21, 2011 at 14:33:08 (CEST), Cliff Stewart wrote:

> I solved my issue. An applet called indicator-multiload was the culprit.

I'm running indicator-multiload in ubuntu classic mode with gnome panel,
and don't experience the leak. Seems there is some interaction issue
between unity and the indicator applet going on?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Revision history for this message
Nicholas Shatokhin (robotex) wrote :

> I solved my issue. An applet called indicator-multiload was the culprit.
Is memory leak in indicator-multiload? I will try to delete it and check the compiz's memory.

Revision history for this message
Krister Swenson (thekswenson) wrote :

I no longer have the problem if I disable indicator-multiload.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I've lost count of the leaks in unity I've looked at today (to fix bug 769957). My plan is to only fix what I need to to resolve that bug and leave the others to this bug (or others).

The most common cause I've found is total misuse of the nux::Object referencing model throughout the unity code. So often a floating reference is created (one not marked as owned via SinkReference etc) with refcount==1, and the author just calls UnReference which will always fail in that situation. Because nux::Object::UnReference is actually designed to fail in that situation (!)

I think the root cause really is the design of nux::Object. It is far too confusing and dangerous for an object with refcount==1 to fail UnReference. Programmers really don't expect that and it is not obvious why initially (if you even bother to check the return value of UnReference).

For now in bug 769957, I'm just working with the nux API as it is and changing only unity to minimize potential side effects. But it feels inelegant...

Would it ever be safe to make nux::Object::UnReference behave how people expect it should?

Revision history for this message
Peter Petersson (petersson-peter) wrote :

Ty Reinhard/Robotex/Krister I have now also disabled indicator-multiload.
I have only just disabling it a few minutes ago but indicator-multiload seems very likely to be the culprit as compiz (in unity) is no longer eating up the comp:s. memory.

Revision history for this message
Peter Petersson (petersson-peter) wrote :

... cudos Cliff Stewart for finding this one :) compiz is a lot less aggressive in eating memory now, indicator-multiload is either doing something wrong that causes memory leaks in compiz or is in heavy use of some api function that causes this big leak.

Revision history for this message
Nicholas Shatokhin (robotex) wrote :

We must say this to indicator-multiload's creator.

Revision history for this message
Peter Petersson (petersson-peter) wrote :

The indicator-multiload memory leak problem has be reported in #779717

Revision history for this message
Derek Monner (dmonner) wrote :

There is also discussion of indicator-multiload as the source of the memory leak in #720446. Look in particular at comments #42 and #44 there. These say that: 1) the leak does not occur when using indicator-multiload in Classic, only in Unity; and 2) indicator-multi-load is, every second, loading a newly generated icon to display. That would qualify as "heavy use of some api function" as Peter mentioned. This sounds to me like it might be a leak in the above-referenced function which we appear to still be waiting on Jay to look at:

nux::UXTheme::Load2DTextureFile(char const*)

Revision history for this message
Nicholas Shatokhin (robotex) wrote :

indicator-multiload in classic ubuntu and in unity are different things. The has different source code.

Revision history for this message
Derek Monner (dmonner) wrote :

@Robotex: Yes, that's true, but it misses the point I was trying to make. There is the system indicator applet (which lives in the gnome panel) that *looks* just like indicator-multiload (which lives in the indicator area), and I agree that these are different programs with different codebases. Only the latter is usable in Unity. Obviously the gnome panel applet, which is only usable in classic, is not leaking. However, one can use indicator-multiload, in the indicator area, in classic mode as well. In this case, it does not appear to cause a leak. Only when run under Unity does the indicator-multiload cause a memory leak.

Revision history for this message
Michael Hofmann (mh21) wrote :

For the indicator-multiload leak, there is a nice valgrind log at https://launchpadlibrarian.net/72194098/valgrind.log (from bug #786425):
==2761== 2,305,980 (45,084 direct, 2,260,896 indirect) bytes in 867 blocks are definitely lost in loss record 11,053 of 11,054
==2761== ...
==2761== by 0x939692C: gdk_pixbuf_new
==2761== ...
==2761== by 0x7DBE846: IndicatorObjectEntryProxyRemote::GetPixbuf()
==2761== by 0x7DEF2F1: PanelIndicatorObjectEntryView::Refresh()
==2761== ...
==2761== by 0x7DBEF60: IndicatorObjectEntryProxyRemote::Refresh(...)
==2761== by 0x7DC24B6: IndicatorObjectProxyRemote::AddEntry(...)
==2761== by 0x7DC1156: IndicatorObjectFactoryRemote::Sync(...)
==2761== ...

Revision history for this message
Krister Swenson (thekswenson) wrote :

@Daniel van Vugt: i stand corrected as there do seem to be minor leaks still. good work.

Revision history for this message
Derek Monner (dmonner) wrote :

Over in #779717 (comment #18), Michael Hofmann has a patch for Unity that seems to fix the memory leak that is so noticeable when indicator-multiload is running.

Revision history for this message
Jay Taoko (jaytaoko) wrote :

@Derek Monner
I have submitted a fix to nux/0.9 trunk for the leak in nux::UXTheme::Load2DTextureFile(char const*)

Revision history for this message
Jay Taoko (jaytaoko) wrote :

@Daniel van Vugt
I will change the behavior of Object::UnReference. I think we could make it so that it releases objects with a floating reference. Right now, you have to call Object::Dispose to release an object that has a floating reference.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thanks Jay. I will try that change too and then only worry about the remaining leaks after that. Changing just Object.cpp in nux should eliminate the need to fix much of the unity code, or even worry about finding all instances of that mistake.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I have tested my suggestion - removing the "if (!OwnsTheReference() )" blocks from Object::Reference and Object::UnReference.

The good news:
* Unity is stable with the change.
* The corruption described in bug 769957 and seemingly due to window/nux leaks is half fixed (but not fully)

The bad news:
* compiz average memory usage seems to be LARGER, not smaller.

So it seems on average, fixing the reference count to be larger when it should be larger actually means that broken client code (unity) which is missing the required number of Dispose/UnReference calls now leaks in places it didn't before. This makes sense if you imagine that floating references assigned to container objects are more common than non-contained floating references.

So sadly not a change I can recommend right now.

A more defensive and more compatible fix involves fixing the floating references (mostly in unity?) one-by-one :(

I strongly suggest separating each type of leak into a separate bug, where the code changes and valgrind results are small and individually verifiable. The Load2DTextureFile leak is one such example. That can be a bug in itself.

It's probably not realistic to continue trying to fix everything in this one bug and then say "the leaks in compiz are now all fixed".

Jay Taoko (jaytaoko)
Changed in nux:
status: Triaged → In Progress
Changed in unity:
status: Triaged → In Progress
Changed in compiz (Ubuntu):
status: Triaged → In Progress
Changed in nux (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nux - 0.9.48-0ubuntu4

---------------
nux (0.9.48-0ubuntu4) oneiric; urgency=low

  * Cherry-pick more fixes:
    - input characters become invisible on switching dash to fullscreen mode
      (LP: #758248)
    - Fixed memory leak. Related to bug (LP: #758248)
    - Fix compiz crashed with SIGSEGV in nux::NThreadSafeCounter::Decrement()
      (LP: #763225)
 -- Didier Roche <email address hidden> Thu, 26 May 2011 17:01:57 +0200

Changed in nux (Ubuntu):
status: In Progress → Fix Released
Changed in nux:
status: In Progress → Fix Released
Jay Taoko (jaytaoko)
description: updated
Changed in unity:
status: In Progress → Fix Released
Changed in compiz (Ubuntu):
status: In Progress → Invalid
Changed in compiz (Ubuntu Natty):
status: New → Invalid
Revision history for this message
Jay Taoko (jaytaoko) wrote :

I have opened up bug #788689. There I will be investigating the removal of Object::Dispose() in favor of Object::UnReference().

Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Accepted nux into natty-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!

Changed in nux (Ubuntu Natty):
status: New → Fix Committed
tags: added: verification-needed
Revision history for this message
Michael Vogt (mvo) wrote :

The fix in natty-proposed works for me, since I installed it a couple of hours ago I see stable memory usage with unity.

Revision history for this message
Achim (ach1m) wrote :

I am not sure if the problem has been fixed. Memory usage is still growing for me.
Please see attached file (memory_usage.svg).

With this command
$ ps -C compiz -o rsz
I get the information of memory usage. I have monitored memory usage every 30 seconds.

nux-tools:
  Installiert: 0.9.48-0ubuntu1.1
  Kandidat: 0.9.48-0ubuntu1.1
  Versionstabelle:
 *** 0.9.48-0ubuntu1.1 0
        500 http://archive.ubuntu.com/ubuntu/ natty-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     0.9.48-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ natty-updates/main amd64 Packages
     0.9.46-0ubuntu4 0
        500 http://archive.ubuntu.com/ubuntu/ natty/main amd64 Packages
achim@achim-MS-7521:~/Arbeitsfläche$ apt-cache policy nux-tools unity compiz
compiz:
  Installiert: 1:0.9.4+bzr20110415-0ubuntu2
  Kandidat: 1:0.9.4+bzr20110415-0ubuntu2
  Versionstabelle:
 *** 1:0.9.4+bzr20110415-0ubuntu2 0
        500 http://archive.ubuntu.com/ubuntu/ natty/main amd64 Packages
        100 /var/lib/dpkg/status
unity:
  Installiert: 3.8.14-0ubuntu1~natty1
  Kandidat: 3.8.14-0ubuntu1~natty1
  Versionstabelle:
 *** 3.8.14-0ubuntu1~natty1 0
        500 http://archive.ubuntu.com/ubuntu/ natty-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     3.8.12-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ natty-updates/main amd64 Packages
     3.8.10-0ubuntu2 0
        500 http://archive.ubuntu.com/ubuntu/ natty/main amd64 Packages
nux-tools:
  Installiert: 0.9.48-0ubuntu1.1
  Kandidat: 0.9.48-0ubuntu1.1
  Versionstabelle:
 *** 0.9.48-0ubuntu1.1 0
        500 http://archive.ubuntu.com/ubuntu/ natty-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     0.9.48-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ natty-updates/main amd64 Packages
     0.9.46-0ubuntu4 0
        500 http://archive.ubuntu.com/ubuntu/ natty/main amd64 Packages

Revision history for this message
Pedro Villavicencio (pedro) wrote :

This is working fine for me as well, I'm marking it as verification-done so it can go trough updates, if you see more memory usage problems please open a new bug report, thanks in advance.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nux - 0.9.48-0ubuntu1.1

---------------
nux (0.9.48-0ubuntu1.1) natty-proposed; urgency=low

  * Cherry-pick fixes:
    - for launcher sometimes doesn't hide when there are
      windows beneath it (LP: #772185)
    - input characters become invisible on switching dash to fullscreen mode
      (LP: #758248)
    - Fixed memory leak. Related to bug (LP: #758248)
    - Fix compiz crashed with SIGSEGV in nux::NThreadSafeCounter::Decrement()
      (LP: #763225)
 -- Didier Roche <email address hidden> Thu, 26 May 2011 15:17:53 +0200

Changed in nux (Ubuntu Natty):
status: Fix Committed → Fix Released
Changed in unity (Ubuntu):
status: New → Fix Released
Revision history for this message
Rolf Leggewie (r0lf) wrote :

natty has seen the end of its life and is no longer receiving any updates. Marking the natty task for this ticket as "Won't Fix".

Changed in unity (Ubuntu Natty):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
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.