It does this on trying to load a .ogg file (haven't tried a .mp3 yet). Workaround: disable libmpg123 input plugin. Works fine then. I should note I'm building with -march=k6-2 -mmmx -m3dnow, so it could just be my build. Other things build OK. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 3966)] 0x4068eb14 in get_iplugin_info () from /usr/lib/xmms/Input/libmpg123.so (gdb) bt #0 0x4068eb14 in get_iplugin_info () from /usr/lib/xmms/Input/libmpg123.so #1 0x081dd818 in ?? ()
The problem is most likely with your chosen build options. First of all k6-2 optimizations AND chips are known to have problems and by forcing mmx and 3dnow optimization you are further increasing chances of problems. :) I don't want to just write off your problem as such... but could you reduce your optimizations down to -i686 -O3 -pipe and let me know if you experience the same problem... and is it just with ogg files or is it also with mp3 files?
I'm rebuilding having commented out the USE and CFLAGS stuff in /etc/make.conf. Note that I'm getting -mcpu=i686, even tho' I have CHOST="i586-pc-linux-gnu" so there may be a new portage bug, unless this is intentional. Sample compile: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -D_REENTRANT -I/usr/X11R6/include -O2 -mcpu=i686 -pipe -Wall -Wpointer-arith -finline-functions -ffast-math -fomit-frame-pointer -funroll-all-loops -DDATA_DIR=\"/usr/share/xmms\" -DPLUGIN_DIR=\"/usr/lib/xmms\" -DPLUGINSUBS=\"Output\",\"Input\",\"Effect\",\"General\",\"Visualization\" -DLOCALEDIR=\"/usr/share/locale\" -DI386_ASSEM -I../intl -O2 -mcpu=i686 -pipe -Wall -Wpointer-arith -finline-functions -ffast-math -fomit-frame-pointer -funroll-all-loops -c general.c Results after new build: bug gone. Apparently something in the build flags was involved. If you have recommendations for USE and CFLAGS for a k6-2, please let me know. Below is what I was using: USE="acpi acpi4linux xfs gtk gtk2 gnome mbox alsa xmms mmx 3dnow opengl \ matrox dga cdr bonobo pic leim -cups -apm -postgres -dvd -kde -qt -nls" CHOST="i586-pc-linux-gnu" CFLAGS="-march=k6-2 -O3 -pipe" I'll probe the USE/CFLAGS space a bit and try to find the actual culprit. The following is more info on the crash I was getting with the CFLAGS and USE flags I was using: The crash is being caused by using the 'detect file type by content' option of the mpg123 plugin. I rebuilt, dropping the -mmmx and -m3dnow flags but keeping the -O3 and -march-k6-2. I experimented with switching the decoder optimisation from 3dnow to fpu, but the crash is still there. Also, the crash seems be happening only when the plugin is autodetecting ogg files, not mp3 files. It might still be my setup, since I'm running bleeding-edge everything (including of course an overclocked chip), and I've seen other crashes in multimedia-type things which makes me suspect either the chip's handling of mmx and 3dnow, or the code gcc generates. But everything else, including gcc, X and the kernel are stable, so the rig is basically stable.
As you have an overclocked k6-2 I am going to not look too much more seriously into this as a bug. A k6-2 will be recognized as an i686 chip such so that is normal. -mcpu=i686 or -march=i686 should work fine... cpu is probably a better choice as it is a good chance that an overclocked k6-2 will fry one of these days and you'll probably replace it eventually with a different chip. :) -O3 is fine but I have found more stability using -O2 without any noticable speed loss... (i haven't done in-depth research taking hundredths of a second differences but apps aren't slow by any means) Also if you ever plan on doing debugging then -O2 is a good choice. -pipe is fine. Being on the "bleeding edge" of gentoo isn't really "unstable" in my eyes... but that's just my opinion :) most applications work rather well that are marked unstable. Anyway... thanks for using Gentoo :)
Actually, the beauty of the k6 is that they don't fry... if you push them too far, they get flaky and you back off. I ran a k6-2/300/66 as a k6-2/333/95 for years, finally made the leap to a k6-2/533/100, which I've only pushed to 550/100 (and had to overvolt it to 2.3v, so maybe it will fry, big loss...), and they seem to either be stable or not. If they aren't, X crashes, gcc compiles fail, etc.; it's pretty clear what's up. So I think the chip is as OK as it will get. I probed the USE/CFLAGS space, and it appears there is only a problem with -march=k6-2. -O3 is fine, as are all the USE flags I was using (see below). My conclusion is that this is probably a gcc bug involving the k6-2, unless it is a chip bug that only emerges when gcc generates correct k6-2-tuned code. As I mentioned, I've noticed crashes with other things that might be using k6-2-3dnow-tuned code, such as gxine, mplayer, etc. Thanks for your CFLAGS recommendations. The current Gentoo defaults are apparently -mcpu=i686 -O2 -pipe, so I think I'll just comment out my CFLAGS stuff entirely. My doubt about i686 came from the setiathome client, where it is explicitly stated that the i686 build won't work on a k6 (forget if they said k6-2 or not). USE flags used by xmms; x86 mmx gnome 3dnow esd mikmod opengl oggvorbis
Just for yucks, I checked some more gcc flags: Rebuilt with -mcpu-k6-2 -O2. Crashed. Sad... Rebuilt with -mcpu-k6 -O2. Crashed. Pathetic... I guess I'll start watching gcc k6 bugs...
I finally, by use of gdb and repeated remaking with different compile options, tracked this bug down as a k6+optimise+loop-unroll gcc bug, and confirmed this with a gcc developer (see appended). I'll file a gentoo gcc bug report to encourage picking up a new snapshot. developer says: Ok. This testcase is correctly compiled by the current 3.2 branch so your problems will very likely vanish by upgrading to the upcoming 3.2.2 official release. Here's the story: gcc 3.2.1 shipped with a wrong-code generation bug, regression from gcc 3.2, for the following loop construct compiled with -mcpu=k6 -O2 -funroll-loops for (i=0; i<n; i++) array[i] = 0; when (n%4 == 0). It was reported as PR optimization/8599. The bug had already been fixed on the mainline (future 3.3 release) so I backported the fix to the 3.2 branch. Now it turned out that the fix for the mainline was not valid for the branch (still unclear why...) so, while fixing the problem exposed above, it broke the very same loop construct for (i=0; i<n; i++) array[i] = 0; this time when (n%4 != 0). How embarassing... So I reverted the backport patch and, after some analysis, came up with what I think is the correct fix for the 3.2 branch, which is in since then. Now, according to the version string of your snapshot, it was checked out from the repository during the period when the _wrong_ fix was on the branch (see the dates in the audit trail of PR optimization/8599). Hence very likely the problems you ran into.
db fix
