The program audacious seems to have a very bad memory leak. When only having it open memory usage increases over time (several hundreds MB per day) even when not playing any music. The only things open are the player itself and its playlist. Maybe it is caused due to some problems with gtk2? I am using the skin maXMMS installed via x11-themes/audacious-themes-0.0.3 (just to make sure all stuff is reproduceable). I already had this problem in earlier versions of audacious and the kernel (gentoo-sources, too) so I can't say when it did start. Here is the list of software installed: media-sound/audacious-1.2.0_rc3 USE="nls -chardet -gnome" x11-themes/audacious-themes-0.0.3 media-plugins/audacious-plugins-1.2.1 USE="alsa arts esd mmx mp3 nls oss vorbis -aac -flac -jack -lirc -modplug -musepack -pulseaudio -sid -sndfile -timidity -wma" x11-libs/gtk+-2.10.6 USE="X jpeg tiff xinerama -debug -doc" emerge --info Portage 2.1.2_pre3-r5 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.5-r0, 2.6.18 i686) ================================================================= System uname: 2.6.18 i686 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.5 Last Sync: Thu, 19 Oct 2006 15:00:01 +0000 ccache version 2.4 [enabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 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, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -msse2 -pipe -O2" CHOST="i686-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="-march=athlon-xp -msse2 -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sfperms" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="de_DE@euro" LC_ALL="de_DE.utf8" LINGUAS="de" 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" PORTDIR_OVERLAY="/portage-overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X acpi alsa apache2 apm arts avi bash-completion bitmap-fonts bzlib caps cdr cli cracklib crypt cups dbus divx4linux dlloader dri dvd dvdr dvdread eds elibc_glibc encode esd ffmpeg fortran ftp gcj gdbm gif gimp gpm gstreamer gtk gtk2 hal imagemagick imlib input_devices_keyboard input_devices_mouse ipv6 isdnlog java javascript jpeg kde kdeenablefinal kernel_linux libg++ libwww linguas_de mad matroska mikmod mmx motif mp3 mpeg ncurses nls no-seamonkey nocd nptl nptlonly nsplugin ogg oggvorbis opengl oss pcre pdf perl png pppd python qt qt3 qt4 quicktime readline real reflection samba scanner sdl session spell spl sse sse2 ssl svg theora tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU v4l vcd video_cards_r300 video_cards_radeon video_cards_vesa videos vorbis win32codecs wxwindows xcomposite xinerama xml xml2 xmms xorg xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS If any infos are missing, just ask.
If you can do a debug build and use valgrind, I'll try to figure it out... It doesn't leak for anyone else though; the issue seems to be solely with your setup as far as I know.
You should not be specifying -msse, let alone -msse2. Remove this and emerge -e world if you want support.
(In reply to comment #2) > You should not be specifying -msse, let alone -msse2. Remove this and emerge -e > world if you want support. > Actually, -msse should be fine with -march=athlon-xp. If he wants the proper optimisation for an Athlon 64, then he should use -march=k8, with which, -msse2 should be fine, but not with -march=athlon-xp.
Okay, I did an emerge -e world with the changed make.conf and, who would have thought so, no difference, the leak is still there. Mem usage directly after starting is less than 50MB, 30min later it is above 50MB and keeps raising every don't know how many mins by some MB (something like 4MB jumps every 4mins or so). Here is the (new) output of emerge --info: emerge --info Portage 2.1.2_pre3-r5 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.18 i686) ================================================================= System uname: 2.6.18 i686 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.5 Last Sync: Fri, 20 Oct 2006 14:30:07 +0000 ccache version 2.4 [enabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 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, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon64 -msse2 -pipe -O2" CHOST="i686-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="-march=athlon64 -msse2 -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sfperms" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="de_DE@euro" LC_ALL="de_DE.utf8" LINGUAS="de" 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" PORTDIR_OVERLAY="/portage-overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X acpi alsa apm bash-completion bitmap-fonts bzip2 cdinstall cdr cli cracklib crypt cups dbus divx4linux dlloader dri dvd dvdr dvdread elibc_glibc encode ffmpeg firefox fortran ftp gcj gdbm gpm gtk gtk2 hal iconv icq imagemagick input_devices_keyboard input_devices_mouse ipv6 isdnlog java javascript jpeg kde kdeenablefinal kernel_linux libg++ linguas_de lm_sensors matroska mmx mp3 mpeg ncurses nls no-seamonkey nocd nptl nptlonly nsplugin ogg opengl pcre pdf perl png ppds pppd python qt3 qt4 quicktime readline recode reflection samba scanner sdl session spell spl sse sse2 ssl svg theora truetype truetype-fonts type1-fonts udev unicode usb userland_GNU v4l vcd video_cards_r300 video_cards_radeon video_cards_vesa videos vorbis win32codecs wxwindows xcomposite xine xinerama xml xmms xorg xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS So this report does not really look invalid to me since the whole system was recompiled with options that *should* work. If you can provide me with detailed instructions on how to do a debug build and get through it with valgrind I could try to get some more infos for you.
I just noticed that you are running gcc 4.1.1. I would recommend that you use 4.1.1-r1 due to the fact that it fixes several bugs in the branch optimizer on x86/amd64. Not sure if that fixes your bug or not though, but it is very likely related. 4.1.1-r1 may still be in unstable, though.
I experience this problem with audacious-1.1.2-r1 which is "stable" :-( # emerge --info Portage 2.1.1 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 i686) ================================================================= System uname: 2.6.17-gentoo-r8 i686 Intel(R) Pentium(R) M processor 1600MHz Gentoo Base System version 1.12.5 Last Sync: Mon, 23 Oct 2006 04:50:01 +0000 ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 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.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium-m -O2 -pipe" CHOST="i686-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/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=pentium-m -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer nostrip sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="cs_CZ.UTF-8" LC_ALL="cs_CZ.UTF-8" LINGUAS="cs" 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" PORTDIR_OVERLAY="/root/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 X aac aiglx alsa amr berkdb bitmap-fonts cli crypt cups dga dlloader dri elibc_glibc encode ffmpeg flac fortran gdbm gif gpm hpn imlib input_devices_keyboard input_devices_mouse ipv6 isdnlog java jpeg jpeg2k kde kdehiddenvisibility kernel_linux ldap libg++ linguas_cs logrotate mad mikmod mmx mp3 mp4 mpeg ncurses nls nptl nptlonly nsplugin ogg opengl pam pcre pda perl png ppds pppd python readline reflection samba scanner sdl session smartcard spl sse2 ssl symlink tcpd theora tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU video_cards_i810 video_cards_vesa vorbis x264 x509 xcomposite xmms xorg xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Hi, same problem here. This bug was easy to trigger for me when I started audacious in a KDE-session and then switch betweeen virtual desktops. With every switch the total RAM usage increased about 7 - 20 MB which was all caused by audacious. I managed to make my system completely unuseable by this bug when my RAM and swap were completely full after a while. This is a real showstopper for audacious. And THIS should become the replacement for XMMS? o.m.g. Portage 2.1.1-r1 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.17.13 i686) ================================================================= System uname: 2.6.17.13 i686 AMD Athlon(tm) XP 3000+ Gentoo Base System version 1.12.5 Last Sync: Mon, 23 Oct 2006 18:00:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 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, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -mtune=athlon-xp -O3 -pipe -frename-registers" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /home /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/X11/Sessions /etc/X11/app-defaults /etc/X11/mwm /etc/X11/wmconfig /etc/X11/xinit /etc/bash_completion.d /etc/bonobo-activation /etc/cups /etc/dbus-1 /etc/dev.d /etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/fonts /etc/foomatic /etc/gconf /etc/gimp /etc/gnome-vfs-2.0 /etc/gtk /etc/gtk-2.0 /etc/hotplug /etc/hotplug.d /etc/imlib /etc/init.d /etc/iproute2 /etc/java-config/vms/ /etc/nas /etc/ntop /etc/pam.d /etc/pango /etc/profile.d /etc/revdep-rebuild /etc/sasl2 /etc/sgml /etc/ssl /etc/ssmtp /etc/t1lib /etc/terminfo /etc/xinetd.d /etc/xml" CXXFLAGS="-march=athlon-xp -mtune=athlon-xp -O3 -pipe -frename-registers -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--alphabetical" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror ftp://ftp.tu-clausthal.de/pub/linux/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LDFLAGS="-Wl,--as-needed" LINGUAS="de" PKGDIR="/home/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="/home/portage/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://192.168.0.254/gentoo-portage" USE="x86 3dnow 3dnowext X a52 aac acpi alsa arts asf avi berkdb bitmap-fonts bluetooth bzip2 cairo cdparanoia cdr cli cracklib crypt cups dri dvd dvdread elibc_glibc emboss encode fam ffmpeg flac gdbm gif gnutls gpg gtk gtk2 idn imagemagick imlib input_devices_keyboard input_devices_mouse isdnlog jpeg kde kdehiddenvisibility kernel_linux libg++ libwww linguas_de mad mikmod mjpeg mmx mmxext mp3 mpeg ncurses nls nptl nptlonly nsplugin ogg oggvorbis opengl pam pcre perl png ppds pppd python qt3 quicktime readline real reflection samba sdl seamonkey session silc slang spell spl sse ssl svg tga theora tiff truetype truetype-fonts type1-fonts udev userland_GNU vcd video_cards_nv video_cards_nvidia vorbis win32codecs x264 xcomposite xml xml2 xorg xprint xv xvid zlib" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS # emerge -pv audacious{,-plugins} These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-sound/audacious-1.2.0_rc3 USE="-chardet -gnome nls" 0 kB [ebuild R ] media-plugins/audacious-plugins-1.2.1 USE="aac alsa -arts -esd flac -jack -lirc -modplug mp3 -musepack nls -oss -pulseaudio -sid -sndfile -timidity vorbis wma" 0 kB Cheers Poly-C
maybe related to this bug? http://bugs.nenolod.net/view.php?id=556 Though the bug is marked as fixed, I'm quite sure, that the described symptoms there are similar to the one I encountered. This would also explain the memory leaks when I switch virtual desktops. I have different backgroundimages on all of my vdesktops. Also changing the backgroundimage of the vdesktop, where audacious is placed, via kcontrol makes audacious eating up more and more memory. Cheers Poly-C
Created attachment 100349 [details, diff] audacious-playlist-transparency-leakfix.diff This fixes the memory leaks in the psuedo-transparency code. It is against 1.2, but can be easily adapted against 1.1.2 as well. From 1.2 SVN (myself).
This has been addressed in upstream SVN, and will be in the 1.2 final release. You will have this in portage within the next few hours. "And THIS should become the replacement for XMMS? o.m.g." <- XMMS never had transparent background support, so to make the comparison fair, you would have turned this option off anyway.
(In reply to comment #10) > XMMS never had transparent background support, so to make the comparison > fair, you would have turned this option off anyway. but Audacious has it turned on by default, so you have to look at the comparsion from the point of view that XMMS does not crash "out of the box" :-p
Alright I just rechecked this to be sure... I had playlist-transparency DISABLED when I found this bug. Applying the patch from comment #9 also has no effect, I still have huge memleaks in audacious as soon as the backgroundimage changes. Poly-C
Alright, then please report your bug in the upstream bug tracker if you haven't already done so.
(In reply to comment #12) > Alright I just rechecked this to be sure... > I had playlist-transparency DISABLED when I found this bug. > Applying the patch from comment #9 also has no effect, I still have huge > memleaks in audacious as soon as the backgroundimage changes. > > Poly-C > This fixes the bug. Sorry. It does. If it doesn't produce a patch that fixes it on KDE. (In reply to comment #11) > (In reply to comment #10) > > XMMS never had transparent background support, so to make the comparison > > fair, you would have turned this option off anyway. > > but Audacious has it turned on by default, so you have to look at the > comparsion from the point of view that XMMS does not crash "out of the box" :-p > No it does not have it turned on by default. Go troll elsewhere.
(In reply to comment #14) > (In reply to comment #12) > > Alright I just rechecked this to be sure... > > I had playlist-transparency DISABLED when I found this bug. > > Applying the patch from comment #9 also has no effect, I still have huge > > memleaks in audacious as soon as the backgroundimage changes. > > > > Poly-C > > > > This fixes the bug. Sorry. It does. If it doesn't produce a patch that fixes it > on KDE. Sorry to tell you, but on my System the bug is not fixed though I am using the freshly released 1.2 where the patch should be included. I don't understand your argument that the patch would fix the bug while it can still be observed. I never had transparency activated but it is somehow related to the desktop pic changeing. At least when you are using kdesktop to automatically switch the wallpaper you can easyly observe that this bug still is valid. I have no idea if this bug is really only happening when using kde with audacious but it really does look like. I am not a coder myself (at least not in c/c++) so I am not able to preoduce a fix for it myself. All that I can now help with is providing a way to reproduce the bug: 1) start X using kde. 2) select "automatic switching of wallpapers" in kDesktop (changing the pic every minuite to increase the growth of the memory) 3) start audacious (settings in audaciuos for transparency do *not* seem to matter at all) 4) have a look at the mem usage growing whenever the wallpaper changes. This does look like a bug to me and here is even an easy way to reproduce it. That is already a nice start for fixing it.
Created attachment 100409 [details, diff] audacious-playlist-transparency-leakfix-try2.diff This version should fix the KDE-specific issues too. We're releasing 1.2.1 of the player later today.
audacious-1.2.0 + patch from comment #16 is still leaking on kde-3.5.5
(In reply to comment #17) > audacious-1.2.0 + patch from comment #16 is still leaking on kde-3.5.5 > How exactly are you testing this?
Thank you for the upstream bug. 1.2.1 will have fixed this.
Well, I took audacious-1.2.0, applied the patch (the part that is still missing from 1.2.0), built and installed audacious. Then I started audacious + xosview + htop (letting htop sort by MEM% usage) all in a kde-3.5.5 session. I have six virtual desktops running and every virtual desktop has a different backgroundimage. When I now switch between any of my virtual desktops, I can see in xosview that memory usage is increasing instantly about 5 - 12 MB per switch. When RAM is full and I continue switching between desktops swap gets also filled. Closing audacious frees all the occupied memory again. So my conclusion is that this bug is still persistent in audacious (or KDE is buggy in a way no other app than audacious ever triggered this). I hope this helps a bit... Cheers Poly-C
(In reply to comment #20) > Well, I took audacious-1.2.0, applied the patch (the part that is still missing > from 1.2.0), built and installed audacious. > Then I started audacious + xosview + htop (letting htop sort by MEM% usage) all > in a kde-3.5.5 session. I have six virtual desktops running and every virtual > desktop has a different backgroundimage. When I now switch between any of my > virtual desktops, I can see in xosview that memory usage is increasing > instantly about 5 - 12 MB per switch. When RAM is full and I continue switching > between desktops swap gets also filled. Closing audacious frees all the > occupied memory again. > So my conclusion is that this bug is still persistent in audacious (or KDE is > buggy in a way no other app than audacious ever triggered this). > > I hope this helps a bit... > > Cheers > Poly-C > Try it in 1.2.1, and make sure you use --prefix=/usr
I compiled audacious r2764 [same as 1.2.1-release] and set my KDE background to iterate randomly through a list of images to simulate the different-background issue you raised. Result: No leak after five minutes of playing music.
I used an altered ebuild to install 1.2.0 + patch so --prefix=/usr was used. Version 1.2.1 fixes the big memleak. A small leak still seems to be present but hard to trigger. After installation of 1.2.1 I did the same procedure as described in my previous post. The strange thing is, when I switch the desktop, mem gets increased for about 5 MB and some seconds later decreased for the same amount (5 MB). But sometimes mem increases more than 5 MB (between 7 and 11 MB) and then the decrease is always ${increased amount} minus 1MB. So when a big increase occurs (which happens rather seldom) it always leaves 1 MB of occupied mem back. Cheers Poly-C
(In reply to comment #14) > (In reply to comment #11) > > (In reply to comment #10) > > > XMMS never had transparent background support, so to make the comparison > > > fair, you would have turned this option off anyway. > > > > but Audacious has it turned on by default, so you have to look at the > > comparsion from the point of view that XMMS does not crash "out of the box" :-p > > > > No it does not have it turned on by default. Go troll elsewhere. sorry, my mistake, I did not verify the facts :-( my reasoning was: A) I experience the memory leak B) the leak is in transparency code (from comment #9 - fix for transparency - and #10 - in reaction to "OMG it has terrific leak" it is spoken about transparency) C) I did not tweak any settings, I just run 'emerge -av audacious' and then 'audacious *mp3' so from A & B => I have to have transparency on, and thus (A & B) & C => the transparency has to be on by default but if the above is wrong (transparency is not on by default), then some of A, B or C has to be wrong ... and since I know exactly A and C, the error has to be in B so, it's sad if you see this as trolling, but I am not the one to blame - as Nils already writes in comment #15, you are simply wrong about the cause of the leak (please do not take it as a personal attack, I appreciate your work on this, but I just have to justify myself - you see there are two more users that still have troubles, so you may have fixed _another_ leak?)
(In reply to comment #24) > (In reply to comment #14) > > (In reply to comment #11) > > > (In reply to comment #10) > > > > XMMS never had transparent background support, so to make the comparison > > > > fair, you would have turned this option off anyway. > > > > > > but Audacious has it turned on by default, so you have to look at the > > > comparsion from the point of view that XMMS does not crash "out of the box" :-p > > > > > > > No it does not have it turned on by default. Go troll elsewhere. > > sorry, my mistake, I did not verify the facts :-( > > my reasoning was: > > A) I experience the memory leak > B) the leak is in transparency code (from comment #9 - fix for transparency - > and #10 - in reaction to "OMG it has terrific leak" it is spoken about > transparency) > C) I did not tweak any settings, I just run 'emerge -av audacious' and then > 'audacious *mp3' > > so from A & B => I have to have transparency on, and thus (A & B) & C => the > transparency has to be on by default > > but if the above is wrong (transparency is not on by default), then some of A, > B or C has to be wrong ... and since I know exactly A and C, the error has to > be in B > > so, it's sad if you see this as trolling, but I am not the one to blame - as > Nils already writes in comment #15, you are simply wrong about the cause of the > leak (please do not take it as a personal attack, I appreciate your work on > this, but I just have to justify myself - you see there are two more users that > still have troubles, so you may have fixed _another_ leak?) > The leak is fixed, upgrade to 1.2.1. With XMMS being removed, people have been taking potshots at our attempts in order to try to keep XMMS in the tree, therefore my attitude towards "oh it doesn't really fix it" may be a simple misunderstanding. Do have a good evening, though. :)
One last thing I forgot to mention to clarify why the patch targets what it targets, since some people are confused: Audacious will always cache the background for transparency/other visual effects use. The leak was in that portion of the transparency code and did not matter if the transparency setting was ON or OFF.
Okay, I did run the player for 2 hours with changing backgrounds every minuite (on a 1920x1600 screen). Memory usage at the end was around 22MB. It looks like this leak really is fixed (at least for me). Thanks for your fast work on it.
(In reply to comment #25) > The leak is fixed, upgrade to 1.2.1. I just upgraded yesterday; after half a day usage I do not see any increase in allocated memory, so ... thanks :-) I wonder, why this is still ~arch? btw, I have not tried transparency ... > With XMMS being removed, people have been > taking potshots at our attempts in order to try to keep XMMS in the tree, > therefore my attitude towards "oh it doesn't really fix it" may be a simple > misunderstanding. sorry for being offtopic but I have to react ... as for me, I will miss it but I can live without xmms, just like I can live without my good ol' Speccy, however there are some things ... 1) XMMS was masked without any comparable replacement available (and usable!), which is bad (the latest version of audacious which is marked stable (even now) has a bad memory leak, amarok needs the KDE stuff, rhythmbox needs Gnome stuff, mpd has different philosophy etc.) 2) the masking of XMMS has broken many things - on 3 of 4 of my Gentoo installations I had to manually correct the broken dependencies (while the fourth is server - no multimedia at all so nothing to repair), which is bad ... would it be so hard to wait until the maintainers of all the affected packages remove any connections to xmms, do a revision bump of the affected packages, and mask xmms AFTER that? 3) the responsible people act like gods - WE decided, so YOU, the looser, has to obey, you have no right to tell anything against unless you are going to maintain it yourself or pay a developer for you ... and that is bad too :-( many people would like to help but do not have the posibility to do so (not everyone can speak C :-), so they are volunteering their way - at least giving feedback - and suddenly they are told that they are annoying insect which cannot influence anything and no criticism is allowed ... are you surprised that these people are trying to defend theirs?
