Bug 152001 - media-sound/audacious-1.2.0_rc3 memory leak
|
Bug#:
152001
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: x86
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: chainsaw@gentoo.org
|
Reported By: crazy-ivanovic@gmx.net
|
|
Component: Applications
|
|
|
URL:
|
|
Summary: media-sound/audacious-1.2.0_rc3 memory leak
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2006-10-19 13:04 0000
|
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 an attachment (id=100349) [details]
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.
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?
