XMMS stops with the following message when exiting (don't let the Swedish error messages scare you): ------------------- *** glibc detected *** double free or corruption: 0xbfffec54 *** Avbruten (SIGABRT) ------------------- Avbruten = Aborted (of course) When trying to play a file or read its information (ID3, etc), XMMS segfaults and stops with the following message: ------------------- Segmenteringsfel Du har troligtvis hittat ett fel i XMMS. Var v
XMMS stops with the following message when exiting (don't let the Swedish error messages scare you): ------------------- *** glibc detected *** double free or corruption: 0xbfffec54 *** Avbruten (SIGABRT) ------------------- Avbruten = Aborted (of course) When trying to play a file or read its information (ID3, etc), XMMS segfaults and stops with the following message: ------------------- Segmenteringsfel Du har troligtvis hittat ett fel i XMMS. Var vänlig och gå till http://bugs.xmms.org och fyll i en felanmälan. *** glibc detected *** double free or corruption: 0xbfffec54 *** Avbruten (SIGABRT) ------------------- Segmenteringsfel = Segmentation fault. The second paragraph tells me I've probably found an error in XMMS and to post a bug report at bugs.xmms.org. I would have posted it there if I hadn't noticed the gentoo patches when trying to re-emerge xmms (which did not help). I'm guessing this happened with the glibc upgrade, which includes some sort of double free detection. I just tested it with XMMS 1.2.10-r5 and it's there as well. Reproducible: Always Steps to Reproduce: 1. Install glibc-2.3.4.20041006 2. Install xmms-1.2.10-r7 (or -r5) 3. Start XMMS 4. Exit XMMS, try to play an audio file, or try to look at some file information Actual Results: XMMS segfaults Expected Results: XMMS exits cleanly, plays audio, or displays file information Running xmms-1.2.10-r7, glibc-2.3.4.20041006, kernel 2.6.8-gentoo-r9 in XFce4 and using the Swedish sv_SE locale.
Please try xmms-1.2.10-r8. It is missing some features (cjk and id3v2 eidtor support) which is why it's in package.mask. To try it do this: echo '=media-sound/xmms-1.2.10-r8' > /etc/portage/package.unmask emerge -v '=media-sound/xmms-1.2.10-r8' Did this happen with older versions of glibc? Does this happen with all mp3s you have? Only mp3s with swedish encoded id3 tags?
I'm afraid the bug remains in r8. It emerged fine, though ;-) The bug is also in the older 1.2.8-r4, which won't even start the GUI because of it. It crashes with two segfaults and no glibc reference. As far as I can tell, XMMS will crash whenever it tries to read info from files. This would mean that it's not limited to ID3 tags. In fact, XMMS will crash with the above message when adding any file to the playlist: wav, xm, sid, ogg etc., even non-playable files (text files, etc), and when trying to play the autosaved playlist. It does not seem to be locale-related. Further investigation reveils another hint to what may be happening: when loading an m3u playlist which contains old titles (EXTINF), XMMS does not crash. However, when loading a pls playlist which contains no such info, it will crash. I think, but I'm not sure, that the bug (or rather, the crashes) appeared when I last updated glibc. From emerge.log I get that it was from 2.3.4.20040808-r1 to 2.3.4.20041006. My guess, which should be taken with a grain of salt, is that the new glibc just reacts to faulty XMMS code.
please provide the output of 'emerge --info' as well.
caesar ~ # emerge --info Portage 2.0.51_rc9 (default-x86-2004.0, gcc-3.4.2, glibc-2.3.4.20041006-r0, 2.6.8-gentoo-r9 i686) ================================================================= System uname: 2.6.8-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 2.00GHz Gentoo Base System version 1.5.3 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux-headers-2.4.22 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -mcpu=pentium4 -mtune=pentium4 -O2 -pipe -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -fomit-frame-pointer -msse2" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -mcpu=pentium4 -mtune=pentium4 -O2 -pipe -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -fomit-frame-pointer -msse2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu/ http://ds.thn.htu.se/linux/gentoo ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://mirror.gentoo.no/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d aalib acpi alsa apache2 apm avi berkdb bitmap-fonts cdr crypt cups dba divx4linux emacs encode esd f77 flac foomaticdb gd gdbm gif gnome gpm gtk gtk2 guile icq imlib jabber java jpeg kde kerberos libg++ libwww mad mikmod motif mpeg msn mysql ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline ruby scanner sdl slang spell ssl svg svga tcltk tcpd tetex theora tiff truetype unicode videos x86 xml2 xmms xprint xv xvid zlib"
Looking through my emerge-info, I just realized I compiled glibc with linux 2.4-headers. I'll try to fix that, reemerge glibc and try XMMS again.
Reemerging glibc with 2.6 headers did not help the XMMS problem.
For what it's worth, I installed XMMS manually from xmms.org vanilla sources, and it crashed just as bad as before. Since noone else is complaining, I guess something is borked on my system. Strange, though, that it only seems to affect XMMS.
I already posted this in the forums: The new glibc broke my xmms. After start, xmms uses about 20% of my CPU, and it can't play mp3s any more (it plays for about half a second, then waits a long time at high cpu, plays again a little...) I re-emerged xmms using new glibc, same problem, so I went back to old glibc. This problem is reproducable: After I upgraded glibc on another machine (similar USE/CFLGAGS, but different CPU), xmms shows same behaviour there: Very slow starup (takes 30seconds until xmms-window appears) and so on... This also happens with glibc-2.3.4.20041021
The problem I described before doesn't appear when building glibc without nptl.
I don't recognize the behaviour you're describing. In fact, I don't even have nptl enabled. "emerge -pv glibc" shows the following flag-usage: -build -debug -erandom -hardened -multilib +nls -nptl -nptlonly -pic -userlocales
this isnt a bug in glibc, but a bug made more visible by new glibc sanity checks. re-assigning.
does this only appear with swedish ID3 tags? Can you please give me an mp3 that exhibits this bug? Can you get me a backtrace, so I can see where it's aborting? Thanks.
Jeremy Huddleston, I'd give you a backtrace if only I knew how to. Any instructions? As for the other questions; to clear things up: *** This is not limited to ID3 tags (and thus not Swedish-encoded ID3 tags). Maybe I was being unclear in my initial post. Any time XMMS tries to read information from a file -- be it mp3, ogg, xm, wav, flac -- it will crash, no matter if there is any information to read or not. In practice, this means that XMMS: + WILL crash when trying to add any files, even for unrecognized file types + WILL crash when trying to add URLs + WILL crash when trying to play the file in the old (auto-saved) playlist (xmms.m3u) - will NOT crash on load (because no info is read except for that stored in the old playlist) - will NOT crash when loading a playlist with the entries' names stored in it (for the same reason as above) Now, I don't know if this is related or a separate bug, but since my last report here another bug has started to block xmms from even opening it's window: -------- Gtk-WARNING **: Unable to locate image file in pixmap_path: "textures/Modern.xpm" line 232 [multiple...] /usr/lib/xmms/Input/xmp-plugin.so: undefined symbol: flt_load Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72: _dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx' failed! -------- Removing xmp-plugin.so brings back the old, but also dysfunctional behaviour.
Can youu try recompiling all your installed xmms plugins. You can find out what these are by running this: for f in `find /usr/lib/xmms -type f`; do qpkg -I -v -nc -f $f; done | sort | uniq To get the backtrace, recompile xmms with the following at the end of your make.conf: # # Debug options # CFLAGS="-pipe -g" CXXFLAGS="${CFLAGS}" USE="${USE} debug" FEATURES="${FEATURES} nostrip keeptemp keepwork" then run xmms as normal, and from another console run: $ gdb xmms <pid> gdb) c Now load the mp3 which would cause xmms to abort, and after it aborts, do the following in your debugging console: gdb) bt That should hopefully get a good backtrace for us to use. Please use xmms-1.2.10-r9, so our line numbers match up
I remerged my plug-ins, and lo and behold, XMMS runs like a charm! Thank you very much! (This of course means that I have no backtrace for you.)
yay... closing
