Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Launch xmms from either launcher or terminal 2. in GUI nada - In terminal get segfault 3. Expect xmms to come up and be functional Actual results: in terminal, I get. Segmentation fault You've probably found a bug in XMMS, please visit http://bugs.xmms.org and fill out a bug report. Expected results: unit to function Additional info: I ran strace and saved the output to file. I'll attach it to the bug later on when I can attach items. This is on a complete new install of development packages from yesterday 01/04/04. Jim
Created attachment 96764 [details] This is the output from strace, in a terminal This installation contains no programs from the cd for fedora 1, any updates from test. All updates and installations are from development. version of xmms xmms-1.2.8-4.p requires shows: (verify shows no errors) - Using gnome rpm -q xmms --requires gtk+ >= 1:1.2.2 unzip /usr/share/desktop-menu-patches/redhat-audio-player.desktop redhat-menus >= 0.11 /sbin/ldconfig /sbin/ldconfig rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.3) libdl.so.2 libdl.so.2(GLIBC_2.0) libdl.so.2(GLIBC_2.1) libgdk-1.2.so.0 libglib-1.2.so.0 libglib-2.0.so.0 libGL.so.1 libgmodule-1.2.so.0 libgmodule-2.0.so.0 libgthread-1.2.so.0 libgthread-2.0.so.0 libgtk-1.2.so.0 libICE.so.6 libmikmod.so.2 libm.so.6 libm.so.6(GLIBC_2.0) libogg.so.0 libpthread.so.0 libpthread.so.0(GLIBC_2.0) libpthread.so.0(GLIBC_2.1) libpthread.so.0(GLIBC_2.3.2) libSM.so.6 libvorbisfile.so.3 libvorbis.so.0 libX11.so.6 libXext.so.6 libXi.so.6 libxmms.so.1
Do you have a GDB backtrace?
not yet
Created attachment 96823 [details] gdb trace? Maybe I'm not really being familiar with backtracing with gdb. (newbie) Is this what you wanted to see? If not, what options would give you usable data?
Since I have three Fedora versions running. I decided to copy the .xmms directory from my upgraded development program to my "clean" (only development version. There was none created for the clean development installation. Xmms worked fine with the ~/.xmms plugin directory. It transferred my other installations skin and selected files. The selected links did not work until I created symlinks from the upgrade home ogg directory to the straight development directory. This problem sounds familiar.
Can you run the strace with '-f'?
Created attachment 96872 [details] strace with the -f option I was thinking of creating a new user, but this "user" is new also. I think that xmms will not create the $HOME/.xmms directory also.
You need 'strace -f xmms', not 'strace xmms -f'. Sorry.
Created attachment 96959 [details] strace.xmms (strace xmms -f) I was not sure what the difference with the -f before or after having any working effect. I tried it both ways, then made a diff file of the resulting file differences. I'll also attach the difference with the two files
Created attachment 96960 [details] a differential file for before and after -f option
Created attachment 96964 [details] before (strace -f xmms) the attachments might be duplicated. The diff file might be slightly off keyed. One was run as root and the other was ran as a normal user.
Are you using the alsa output plugin?
no alsa - OSS
due to OSS not being compiled into the kernel any longer, I switched to alsa sound. The creating of a default directory for xmms does not ever get created on initial use. As stated earlier, as long as a directory is already present, xmms will launch alright. ALSA drivers does not make a difference.
It still prints out the error message and does not create an .xmms directory. version xmms-1.2.9-1.p
*** Bug 115523 has been marked as a duplicate of this bug. ***
Please note that in my duplicate bug report i traced this problem to the arts patch (commenting out xmms-1.2.8-arts.patch from the .spec and recompiling fixed the problem). Also, does the "Red Hat Rawhide" product even exist anymore? I thought bug reports on the lastet packages should go into the "Fedora Core" product, version "Devel"?
A lot of choices. I chose rawhide because it was what I thought the bug was related to. Anyway, this bug seems to be present in the Fedora 2 - Test 1 addition by last message that I read from the Fedora List (Regular users list, testing out the new test edition.) It is interesting that you found out that commenting out the arts patch allowed the creation of an .xmms directory. If alsa drivers are to be the default sound drivers, maybe removing arts from the Fedora Core 2 release might get this package ready for test 2 and on. I tried a few different versions of xmms on Fedora Core 1 and they did not cause the segmentation fault. I guess the best move would be to see what interaction that arts-1.1.95-0.1 has with xmms and the arts patch, then resolving the problem. Jim
I deleted the directory for .xmms (renamed actually) - I then installed arts-1.1.4-3 (it had to be nodep'ed and oldpackag'ed to install, kde conflicts). I then ran xmms from a user terminal and the xmms default came to life. I then reinstalled the later version. to see if repeatability = true. I then closed xmms and removed the directory that was created by xmms. I reinstalled arts-1.1.95-0.1 and it segfaulted again. I guess the bug gets reassigned to arts. Later, Jim
I just tried out the arts-1.2.0-0.3 rpm and it still has the problem with the segfaulting. ( latest version for development). I thought that maybe it was revised. I guess the patch to xmms needs upgraded to play well with the new kde arts driver.
I am changing the component responsible to arts. I believe collaboration with the arts maintainer wil aid in resolving the issues with the arts patch in xmms.
added CC for than since this is a component of KDE
*** Bug 115743 has been marked as a duplicate of this bug. ***
*** Bug 115859 has been marked as a duplicate of this bug. ***
*** Bug 116032 has been marked as a duplicate of this bug. ***
*** Bug 116075 has been marked as a duplicate of this bug. ***
After upgrading to: xmms-1.2.9-4.p xmms-skins-1.2.9-4.p and also to: arts-1.2.0-1.4 arts-devel-1.2.0-1.4 Xmms is now able to create a default directory. I still had to go into options and select the alsa drivers, but it works now! Thanks!
Reopening; the patch was just removed. I'd still like to know what's going on here.
Good call! I have a version of xmms-mp3 on one of my test systems that had me decide on staying back until livna updates the mp3 feature. I tried it with the latest arts update and it still segfaulted when trying to launch xmms, without a default directory already. Arts still seems to be the problem. I read somethong about how arts has trouble with oss layers in alsa. Something about low level drivers or similar. I then removed arts entirely. When run in a shell, I get the following error during the prompt. libartsc.so.0: cannot open shared object file: No such file or directory My guess is libartsc. I use Gnome mostly, but install both desktops. Just a another test. (reinstalling arts latest)
> until livna updates the mp3 feature Why? xmms-mp3 for xmms 1.2.9 is available already. There's no need to update the mp3 plug-in for every minor package revision of xmms.
I'll update my links to point to a newer livna location. I believe they still point to Fedora 1 locations. Thanks! I have not tried to run xmms in KDE yet. I guess arts has auto as it's default selection. I read something on setting it to alsa for it not to peg the CPU. Has anyone tried this within KDE yet? Is the problem similar?
arts-1.2 now uses glib2 instead own library, but xmms/plugin is currently a GTK 1 app, using glib1. it looks like that glib1 and glib2 cannot be used together.
Since arts is not compiled with alsa support. Is it possible that the condition that is causing the almost full CPU utilization, is causing xmms to bail out? Being that arts is a KDE sound daemon, why would it use glibc, either version? On the xmms side of things, maybe it should be upgraded to glib2 for better performance and reducing the need to maintain both glib1 and glib2.
Sorry! additional comments! Looking at my rpm requires listing above, xmms seems to be a glib2 application already. See above for 'rpm -q xmms --requires' output.
> Looking at my rpm requires listing above, xmms seems to be a glib2 > application already. See above for 'rpm -q xmms --requires' output. That's because of the arts plugin.
> Since arts is not compiled with alsa support. Where do you see that? It *is* built with ALSA support. Notice the %{alsa} definition and --with-alsa in the spec file. Bug 115507 is the one about arts cpu overload. Why that happens with ALSA's OSS compatibility layer, someone would need to examine. Based on my audio driver programming experience I suspect that artsd makes assumptions about a specific low-level behaviour of the OSS driver (e.g. buffer sizes, blocking/non-blocking times, return codes of state polling functions). When ALSA's OSS compatibility driver behaves differently, the implementation of artsd fails.
i have made a patch in arts, which should fix xmms crash now. could you please upgrade arts-1.2.0-1.5? it should be available soon in rawhide. thanks
As soon as arts hits rawhide, I will give it a go. I imagine that I'll have to drop back a bit for xmms to add the patch for arts back in. Is the version of xmms in the testing repo the latest release, prior to the arts patch removal test?
xmms-1.2.9-5.p will be available in rawhide too.
I upgraded to xmms-1.2.9-5.p and to a arts-1.2.0-1.5. I removed the default .xmms directory, then ran xmms. xmms and arts are getting along together now. Thanks for the resolution. Jim
I spoke too soon. The .xmms directory was created. This closes this bug. arts is not playing well with xmms though. A new bug will be reported on the next problem. Jim
the next chapter of xmms vs arts is committed at below bug. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116764