Bug 2703

Summary:	X resource leak in xcompmgr when using fades
Product:	xorg	Reporter:	Jonathan Briggs <zlynx>
Component:	App/xcompmgr	Assignee:	Xorg Project Team <xorg-team>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	high	CC:	bugs.fdo.org, cafairle, cs
Version:	unspecified
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Jonathan Briggs 2005-03-11 10:49:03 UTC

I noticed that after using xcompmgr with fades enabled for a long time I ran out
of memory.  I checked it out and discovered that not everything was being freed
when a window was destroyed.  Further checking discovered that an Unmap event
queues a fade which finishes the unmap after fading.  But immediately after the
Unmap event a disappearing window gets a Destroy event which queues a window
destroy event and deletes the queued unmap.  This results in the unmap never
running.

There's a "gone" parameter to the destroy functions which is checked to see if
it should run the unmap in the window destroy functions.  I don't understand
what "gone" is supposed to do but it seemed that the check to run unmap if !gone
in finish_destroy_window was backwards so I made it if (gone) instead, and
things seem to be working so far.

Comment 1 Shawn Starr 2005-10-27 19:43:24 UTC

Reporter: Which Xorg version? Can you provide what distribution you are using?
Are you using Xorg CVS?  

Is this a problem still for you?

Comment 2 Jonathan Briggs 2005-10-27 20:36:36 UTC

No, it isn't a problem for *me* because I fixed it.  See the bit about the
change I made inside the finish_destroy_window function.  However, I am not sure
if the change I made was correct.  Someone who knows how that code is *supposed*
to work should look at it and see if I'm right about "if(gone)" instead of
"if(!gone)"

Comment 3 Shawn Starr 2005-10-27 20:45:50 UTC

Can't say, I have the code unchanged in xcompmgr 1.1.2 and but there's been a 
lot of changes in xcomposite. Keeping open until this can be shown there's 
still memory leaks occuring in xcompmgr.

Comment 4 Chris Fairles 2006-02-04 04:43:00 UTC

I have a similar problem, xcompmgr-1.1.3... xrestop shows

res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier    
2200000     1    1    0   71 12891    81713K    302K  82015K   ?   xcompmgr

and it will keep climbing until i kill it and restart. My settings are "xcompmgr
-cCfF -r7 -o.65 -l-10 -t-8 -D7", I'm using xorg7 with libXcomposite-0.2.2.2

I noticed in the function root_tile that a pixmap is created but not freed
before the picture is returned. It looks like all other fn's that return a
picture free it first. 

Going to change that and try Jon's fix to see if the leak disappears.

(using Gentoo btw, gcc-4.0.3)

Comment 5 Chris Fairles 2006-02-05 02:24:48 UTC

Freeing the pixmap in root_tile did not have the desired effect (it made my
desktop manager crash in fact) but changing if(!gone) to if(gone) seems to have
cleared up the leak. xrestop now reports

res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier 
1600000     1    1    0    9 28337    19307K    664K  19971K   ?   xcompmgr

Comment 6 Tilman Sauerbeck 2006-12-03 04:16:16 UTC

Thanks, I committed that change.

Fixed in 6c539182a53a19144edbe1c49fd41c51757173a4.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.