First of all there are no memory leaks in xfce but there are in GNOME. In order to get "composite effects" in GNOME I start "xcompmgr -cCfF -r7 -o.65 -l-10 -t-8 -D7 &" using applet launcher. In a few hours my memory gets almost full. In top I can see that X process consumes too much memory. My memory is approximately 1gb. Killing xcompmgr doesn't help at all. In order to get "composite effects" in XFCE I don't have to do anything. But, in fact, there are no memory leaks in there. I don't know if XFCE uses xcompmgr or not. Portage 2.1.2_pre2-r5 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.4-r4, 2.6.17-suspend2-r6 x86_64) ================================================================= System uname: 2.6.17-suspend2-r6 x86_64 AMD Turion(tm) 64 Mobile Technology MT-32 Gentoo Base System version 1.12.5 Last Sync: Fri, 06 Oct 2006 19:00:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.3-r1, 2.0.28-r1 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=athlon64 -msse3 -pipe -fweb" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=athlon64 -msse3 -pipe -fweb" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="ru" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X a52 acpi alsa apache2 audiofile bitmap-fonts bzip2 cairo cdr cli crypt dbus djvu dlloader doc dvd dvdr dvdread dvi elibc_glibc encode examples fat ffmpeg firefox flac fuse gcc64 gd gdbm gif glibc-omitfp gnome gpm gstreamer gtk hal howl imagemagick immqt input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog java java5 jpeg kde kdeenablefinal kernel_linux libg++ libnotify linguas_ru mad mjpeg mng mp3 mpeg musicbrainz mysql nautilus ncurses nforce2 nls nptl nptlonly nsplugin ntfs nvidia ogg opengl pam pcre pdf pdo plotutils pmu png postgres ppds pppd python quicktime readline reflection reiserfs session sndfile spell spl sqlite ssl subtitles svg symlink tagwriting tcpd theora tidy truetype truetype-fonts type1-fonts udev unicode userland_GNU vcd video_cards_nv video_cards_nvidia video_cards_vesa video_cards_vmware vorbis xfs xine xml xorg xv xvid zip zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY xorg-7.1 gnome-2.14.2 xcompmgr-1.1.3
Hm... It seems fine now. Let me find out everything to be sure. They(xorgers) must have fixed it in the latest update.
Reopen if you can reproduce again.
Yes, I can. But this time X gets bloated much more slower than before(200mb). I will leave my laptop working to see what happens. Hm... I have more info. Just while I was typing the text above I was able to see X bloating much more FASTER. And all was doing was flipping windows with alt+tab. Now after about 10 flips, X consumes 280mb.... It's 5-8mb per flip.
Just to avoid some "works fine for me", try to hang on flipping for a 1-2 minutes to pull the flush-trigger. I also noticed that min./max. make X memory to leak too.
xcompmgr is a proof of concept. It is known to leak things into X memory, and upstream to my knowledge doesn't really care about it as that's what it is - a proof of concept, not meant for daily usage. However I use it myself, and if someone would step up and help upstream patch or maintain it, I'd be glad myself :) Xfwm4 on the other hand has a compositor built in (as does metacity, but disabled and not ready for everyday consumption yet), and so you don't have to use the leaky xcompmgr.
Alright, marking this upstream due to comment #5. I'm setting the URL to the only upstream bug reference to memory leaks in xcompmgr, which is unfortunately a broken bug. Feel free to open another bug upstream, but as Mart said, not much will likely be done unless someone from the community steps up.
From https://github.com/chjj/compton : "Fixes from the original xcompmgr: fixed a segfault when opening certain window types fixed a memory leak caused by not freeing up shadows (from the freedesktop repo) " Maybe not the best place to post but it took me quiete some time to found out another "xcompmgr" :-)
