Bug 162248

Summary:	complete freeze of artsd at video playback
Product:	[Unmaintained] arts	Reporter:	Casteyde.Christian <casteyde.christian>
Component:	artsd	Assignee:	Stefan Westerfeld <stefan>
Status:	CLOSED UNMAINTAINED
Severity:	normal
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Casteyde.Christian 2008-05-18 09:31:59 UTC

Version:           inconnu (using 3.5.9, compiled sources)
Compiler:          Target: x86_64-pc-linux
OS:                Linux (x86_64) release 2.6.25.4

Environment :
This is KDE 3.5.9, with X.org 1.4.

Running Bluewhite 64 (64bit version of Slackare 12.1), but reported to be trans-distro bug by maintainer. This occurs with any X driver (vesa, nv), either in 32 bits mode (with Slackware) or 64 bits (with Bluewhite64).

Last known version that worked: KDE 3.5.7 + X.org 1.3.

Description:

When I click on a video file in konqueror, noatun is started, but it doesn't play anything. Instead, it's completely freezed (GUI not refreshing anymore), and it's impossible to kill it. Moreover, all multimedia feedbacks (such as sound playbacks, etc.) are blocked, and all applications trying to issue them are also blocked waiting for sound termination. In other words, many things are unusable after that, even if the desktop seem to be still partly usable.


Analysis:

I investigated the problem down to artsd, which is blocked in an Xcb exchange with the X server to query for extensions. The call stack of the blocked artsd daemon is the following:
This GDB was configured as "x86_64-pc-linux"...
(no debugging symbols found)
(gdb) r
Starting program: /usr/bin/artsd
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0x7f5594927700 (LWP 11031)]
unix_connect: can't connect to server (unix:/tmp/ksocket-christiancWxktL/athor.localnet-2b0d-482fcc2c)
There are already artsd objects registered, looking if they are active...
... cleaned 5 unused mcop global references.

[New Thread 0x40ba7950 (LWP 11034)]
[New Thread 0x41efd950 (LWP 11035)]
[New Thread 0x413a8950 (LWP 11036)]
[New Thread 0x426fe950 (LWP 11037)]
^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7f5594927700 (LWP 11031)]
0x00007f55919538e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0  0x00007f55919538e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x00007f558e587bcb in ?? () from /usr/lib/../lib/libxcb.so.1
#2  0x00007f558e589635 in xcb_wait_for_reply () from /usr/lib/../lib/libxcb.so.1
#3  0x00007f558e9e5678 in _XReply () from /usr/lib/../lib/libX11.so.6
#4  0x00007f558e9d3d52 in XQueryExtension () from /usr/lib/../lib/libX11.so.6
#5  0x00007f558e9c8b14 in XInitExtension () from /usr/lib/../lib/libX11.so.6
#6  0x00007f558ecaa4b9 in XextAddDisplay () from /usr/lib/../lib/libXext.so.6
#7  0x00007f558bbf47ab in XvQueryExtension () from /usr/lib/../lib/libXv.so.1
#8  0x00007f558bdfd3b6 in ?? () from /usr/lib/xine/plugins/1.20/xineplug_vo_out_xv.so
#9  0x00007f558bdfe3d0 in ?? () from /usr/lib/xine/plugins/1.20/xineplug_vo_out_xv.so
#10 0x00007f558f4f7573 in _x_load_video_output_plugin () from /usr/lib/../lib/libxine.so.1
#11 0x00007f558f4f7629 in xine_open_video_driver () from /usr/lib/../lib/libxine.so.1
#12 0x00007f558f77f79e in xinePlayObject_impl::loadMedia () from /usr/lib/libarts_xine.so.0
#13 0x000000000041163c in ?? ()
#14 0x00007f5594165dd6 in ?? () from /usr/lib/../lib/libkmedia2_idl.so.1
#15 0x00007f5592edff6f in Arts::Dispatcher::handle () from /usr/lib/../lib/libmcop.so.1
#16 0x00007f5592ebccc7 in Arts::Connection::receive () from /usr/lib/../lib/libmcop.so.1
#17 0x00007f5592eee048 in Arts::SocketConnection::notifyIO () from /usr/lib/../lib/libmcop.so.1
#18 0x00007f5592ee55cf in Arts::StdIOManager::processOneEvent () from /usr/lib/../lib/libmcop.so.1
#19 0x00007f5592ee4d56 in Arts::StdIOManager::run () from /usr/lib/../lib/libmcop.so.1
#20 0x000000000041cd74 in ?? ()
#21 0x00007f5590c73164 in __libc_start_main () from /lib/libc.so.6
#22 0x000000000040eee9 in ?? ()
#23 0x00007fff9ca53c78 in ?? ()
#24 0x0000000000000000 in ?? ()
(gdb) quit
The program is running.  Exit anyway? (y or n) y

The server clearly doesn't answer. I didn't know why...
I also used "export LIBXCB_ALLOW_SLOPPY_LOCK=1" just to see, it didn't change anything.


Rationale:

Well, noatun for video playback is not supported, being replaced normally soon. But it is still the defaults player for KDE 3.5.x, and the results is a freezed desktop that would make the casual user simply reboot. So this is important for 'simple' users, that is users that do not know there are other video players sucha as Xine, Mplayer, Kaffeine for instance, and that do not know artsd is the process to kill (with -9 btw).

I suspect a new X.org behaviour, since I checked xine-lib and KDE versions from previous Slackware distribution (which used to work), keeping the latest X.org, and it still fails. I'm considering opening a bug against libxcb.

Comment 1 Casteyde.Christian 2008-05-18 09:37:59 UTC

I've forgotten important info:
xine and mplayer works. Xv is indeed available and workable too.
xvinfo works of course.
This is really specific to artsd video playback (the fact loadMedia works in xine is very interesting btw). It may be due to the context xinelib is used therefore (for instance from a callback in artsd, with some other locks taken, giving a deadlock).
I'm trying to look at other artsd threads and will post results if I find something interesting...

Comment 2 Casteyde.Christian 2008-05-18 10:03:44 UTC

Well, another thread stack is interesting finally:
Thread 2 (Thread 0x42356950 (LWP 14252)):
#0  0x00007f41939c88e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x00007f41907f9a7b in _xcb_lock_io () from /usr/lib/../lib/libxcb.so.1
#2  0x00007f41907f9bda in ?? () from /usr/lib/../lib/libxcb.so.1
#3  0x00007f41907fb2d2 in xcb_wait_for_event () from /usr/lib/../lib/libxcb.so.1
#4  0x00007f4190c57137 in ?? () from /usr/lib/../lib/libX11.so.6
#5  0x00007f4190c57475 in ?? () from /usr/lib/../lib/libX11.so.6
#6  0x00007f4190c3f44f in XNextEvent () from /usr/lib/../lib/libX11.so.6
#7  0x00007f41917ebd71 in xinePlayObject_impl::eventLoop () from /usr/lib/libarts_xine.so.0
#8  0x00007f41917ee1e9 in xinePlayObject_impl::pthread_start_routine ()
   from /usr/lib/libarts_xine.so.0
#9  0x00007f41939c438b in start_thread () from /lib/libpthread.so.0
#10 0x00007f4192d9ff4d in clone () from /lib/libc.so.6

It seems there is a threading model problem in artsd finally. It starts the play object in another thread, but calls loadMedia in the main thread. There are two apartments there, either the call to loadMedia should be done on the worker thread, or the XNextEvent should be done from the main thread I guess. Seems to be an artsd bug only, which is not correct as far as threading is concerned, at least with recent Xcb libraries.

Well, this is only my analysis on code I do not know, only based on my experience on other software (and OSes), so I may also be completly wrong. This is only guesses of course...

Comment 3 Matt Rogers 2008-11-19 23:39:42 UTC

Arts is no longer developed and has been unmaintained for quite some time - more than 2 years. With phonon as the replacement for arts in KDE4, we're closing out all the arts bugs in Bugzilla since there is no chance of them being fixed.

Thanks