Bug 112864 - xmms segfaults
xmms segfaults
Status: CLOSED RAWHIDE
Product: Red Hat Raw Hide
Classification: Retired
Component: arts (Show other bugs)
1.0
i686 Linux
high Severity high
: ---
: ---
Assigned To: Ngo Than
:
: 115523 115743 115859 116032 116075 (view as bug list)
Depends On:
Blocks: FC2Blocker
  Show dependency treegraph
 
Reported: 2004-01-04 15:37 EST by Jim Cornette
Modified: 2005-10-31 17:00 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-23 11:26:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
This is the output from strace, in a terminal (22.15 KB, text/plain)
2004-01-04 15:44 EST, Jim Cornette
no flags Details
gdb trace? Maybe (300 bytes, text/plain)
2004-01-07 21:43 EST, Jim Cornette
no flags Details
strace with the -f option (22.12 KB, text/plain)
2004-01-09 22:06 EST, Jim Cornette
no flags Details
strace.xmms (strace xmms -f) (22.58 KB, text/plain)
2004-01-13 19:09 EST, Jim Cornette
no flags Details
a differential file for before and after -f option (8.83 KB, text/plain)
2004-01-13 19:10 EST, Jim Cornette
no flags Details
before (strace -f xmms) (22.58 KB, text/plain)
2004-01-13 19:15 EST, Jim Cornette
no flags Details

  None (edit)
Description Jim Cornette 2004-01-04 15:37:39 EST
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
Comment 1 Jim Cornette 2004-01-04 15:44:46 EST
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
Comment 2 Bill Nottingham 2004-01-05 02:07:22 EST
Do you have a GDB backtrace?
Comment 3 Jim Cornette 2004-01-06 23:45:37 EST
not yet
Comment 4 Jim Cornette 2004-01-07 21:43:37 EST
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?
Comment 5 Jim Cornette 2004-01-07 22:39:42 EST
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.
Comment 6 Bill Nottingham 2004-01-09 18:31:35 EST
Can you run the strace with '-f'?
Comment 7 Jim Cornette 2004-01-09 22:06:25 EST
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.
Comment 8 Bill Nottingham 2004-01-11 19:06:16 EST
You need 'strace -f xmms', not 'strace xmms -f'. Sorry.
Comment 9 Jim Cornette 2004-01-13 19:09:14 EST
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
Comment 10 Jim Cornette 2004-01-13 19:10:22 EST
Created attachment 96960 [details]
a differential file for before and after -f option
Comment 11 Jim Cornette 2004-01-13 19:15:52 EST
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.
Comment 12 Bill Nottingham 2004-01-14 02:01:20 EST
Are you using the alsa output plugin?
Comment 13 Jim Cornette 2004-01-17 19:52:11 EST
no alsa - OSS
Comment 14 Jim Cornette 2004-01-27 21:33:45 EST
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.
Comment 15 Jim Cornette 2004-01-28 22:24:57 EST
It still prints out the error message and does not create an .xmms
directory.

version xmms-1.2.9-1.p
Comment 16 Bill Nottingham 2004-02-13 15:41:34 EST
*** Bug 115523 has been marked as a duplicate of this bug. ***
Comment 17 Noa Resare 2004-02-13 17:23:28 EST
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"?
Comment 18 Jim Cornette 2004-02-13 20:43:15 EST
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
Comment 19 Jim Cornette 2004-02-13 21:10:32 EST
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

Comment 20 Jim Cornette 2004-02-13 22:21:36 EST
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.

Comment 21 Jim Cornette 2004-02-13 22:30:31 EST
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.
Comment 22 Jim Cornette 2004-02-13 22:33:59 EST
added CC for  than@redhat.com since this is a component of KDE
Comment 23 Bill Nottingham 2004-02-15 22:46:46 EST
*** Bug 115743 has been marked as a duplicate of this bug. ***
Comment 24 Bill Nottingham 2004-02-16 14:07:03 EST
*** Bug 115859 has been marked as a duplicate of this bug. ***
Comment 25 Bill Nottingham 2004-02-17 14:37:52 EST
*** Bug 116032 has been marked as a duplicate of this bug. ***
Comment 26 Bill Nottingham 2004-02-17 22:45:44 EST
*** Bug 116075 has been marked as a duplicate of this bug. ***
Comment 27 Jim Cornette 2004-02-18 17:55:25 EST
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!
Comment 28 Bill Nottingham 2004-02-18 18:32:13 EST
Reopening; the patch was just removed. I'd still like to know what's
going on here.
Comment 29 Jim Cornette 2004-02-18 19:00:51 EST
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)
Comment 30 Michael Schwendt 2004-02-19 02:25:40 EST
> 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.
Comment 31 Jim Cornette 2004-02-19 22:55:04 EST
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?
Comment 32 Ngo Than 2004-02-20 17:06:08 EST
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.
Comment 33 Jim Cornette 2004-02-22 18:34:39 EST
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. 
Comment 34 Jim Cornette 2004-02-22 18:42:06 EST
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.
Comment 35 Bill Nottingham 2004-02-23 00:00:45 EST
> 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.
Comment 36 Michael Schwendt 2004-02-23 05:43:09 EST
> 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.
Comment 37 Ngo Than 2004-02-23 11:26:06 EST
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
Comment 38 Jim Cornette 2004-02-23 22:58:47 EST
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?
Comment 39 Ngo Than 2004-02-24 04:48:36 EST
xmms-1.2.9-5.p will be available in rawhide too.
Comment 40 Jim Cornette 2004-02-24 18:10:22 EST
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
Comment 41 Jim Cornette 2004-02-24 18:17:39 EST
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
Comment 42 Jim Cornette 2004-02-24 18:57:15 EST
the next chapter of xmms vs arts is committed at below bug.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116764

Note You need to log in before you can comment on or make changes to this bug.