compiz close animation is leaking window handles

Bug #954117 reported by Bernd Kreuss
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
compiz (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

This is a major and severe leak, I would classify this as a complete show-stopper because it is not only leaking *huge* amounts of window handles, it will also lead to *insane* amounts of memory leakage.

Steps to reproduce:

* start compiz, use the animations plugin and configure an animation for closing a window.
* start xrestop and carefully watch the numbers reported for "Wins" for the compiz process and also for gtk-window-decorator (or unity-window-decorator)
* additionally start htop and watch overall memory usage and swap usage.

* now open a window (for example start a terminal) and close it again.
* observe the leak of 3 Wins for compiz and 19 Wins for gtk-window-decorator each time you do this.

to make it easier run such a script:

#!/bin/sh

while : ; do
        /usr/bin/xclock &
        sleep .5
        killall xclock
done

(assuming that you have xclock installed and configured a close animation for window type "Unknown"). The above script will make it consume insane amounts of memory with no limit, after running it for 5 minutes it will have started swapping (I have only 500MB RAM total) and after less than half an hour it would have consumed more than 1GB of my Swap and the leaked window handles in xrestop go into the thousands.

The nasty thing about this is that the memory usage will not show up associated to any particular process in ps or top, here all processes seem to behave totally well, neither X nor compiz nor any other process is showing any sign of unusually large RSS usage, all numbers stay constant, yet the total memory and swap usage is increasing linearly over time ad infinitum. The only clue about what is happening is the numbers in xrestop.

If I disable the animations plugin (or even only disable the close animation) it will not leak these handles anymore and memory leak is strongly reduced (not completely gone but significantly reduced).

My system:
IBM ThinkPad T40, ATI Radeon Mobility 7500, xorg radeon driver, 500MB RAM, 1500MB Swap
Ubuntu 11.10, running a very minimal xfce with compiz and gtk-window-decorator

If there is anything I can do to supply additional information, please tell me. I hope somebody else can confirm this behavior.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: compiz 1:0.9.6+bzr20110929-0ubuntu6.1
ProcVersionSignature: Ubuntu 3.0.0-16.29-generic 3.0.20
Uname: Linux 3.0.0-16-generic i686
ApportVersion: 1.23-0ubuntu4
Architecture: i386
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
Date: Tue Mar 13 15:19:09 2012
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=de_DE:de:en_GB:en
 PATH=(custom, user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: compiz
UpgradeStatus: Upgraded to oneiric on 2012-02-26 (16 days ago)

Revision history for this message
Bernd Kreuss (prof7bit) wrote :
tags: added: compiz-0.9
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in compiz (Ubuntu):
status: New → Confirmed
Revision history for this message
void (void-sp) wrote :

I can confirm the leaking of window handles. If I have closing animations enabled - handles leak. If I disable (remove from the plugin's list) all closing animations - handles do not leak. I haven't seen any significant memory leaking however. My config's a bit different though:

video card: ATI Radeon HD4670
driver: fglrx
compiz: 1:0.9.6+bzr20110929-0ubuntu6.2vv1 (from Daniel van Vugt's PPA https://launchpad.net/~vanvugt/+archive/compiz)

I remember when I was using radeon driver though, compiz memory usage would bloat from about 100M to 500M in 1 day uptime (usual activity, no stress tests or anything). So maybe that's the cause...

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.