when I run artsd, it looks something like this: $ artsd There are already artsd objects registered, looking if they are active... unix_connect: can't connect to server (unix:/tmp/ksocket-sruggier/localhost-06eb-4494c558) ... cleaned 5 unused mcop global references. Killed Before I kill it, it locks up indefinitely, using up all the cpu time it can get, and failing to respond to SIGINTs. Here is a backtrace: $ gdb artsd GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/kde/3.5/bin/artsd [Thread debugging using libthread_db enabled] [New Thread -1218832720 (LWP 19379)] There are already artsd objects registered, looking if they are active... unix_connect: can't connect to server (unix:/tmp/ksocket-sruggier/localhost-4bac-4494ce76) ... cleaned 5 unused mcop global references. Program received signal SIGINT, Interrupt. [Switching to Thread -1218832720 (LWP 19379)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7653fe9 in ioctl () from /lib/libc.so.6 #2 0xb7c1e0d6 in snd_pcm_hw_prepare () from /usr/lib/libasound.so.2 #3 0xb7c0e7a2 in snd_pcm_prepare () from /usr/lib/libasound.so.2 #4 0xb7c2cb72 in snd_pcm_rate_prepare () from /usr/lib/libasound.so.2 #5 0xb7c0e7a2 in snd_pcm_prepare () from /usr/lib/libasound.so.2 #6 0xb7db4cc0 in Arts::AudioIOALSA::xrun (this=0x8086f18, pcm=0x80aa560) at audioioalsa9.cc:392 #7 0xb7db4db4 in Arts::AudioIOALSA::write (this=0x80aa8e8, buffer=0x80a9a50, size=1024) at audioioalsa9.cc:445 #8 0xb7dbd1c6 in Arts::AudioSubSystem::handleIO (this=0x807adc8, type=<value optimized out>) at audiosubsys.cc:486 #9 0xb7dbd6c4 in Arts::AudioIOALSA::notifyIO (this=0x8086f18, fd=12, type=<value optimized out>) at audioioalsa9.cc:507 #10 0xb79f0e1f in Arts::StdIOManager::processOneEvent (this=0x8072718, blocking=true) at iomanager.cc:308 #11 0xb79e80b0 in Arts::StdIOManager::run (this=0x8072718) at iomanager.cc:357 #12 0xb79e7fd7 in Arts::Dispatcher::run (this=0xbf92bfa4) at dispatcher.cc:955 #13 0x08059f7f in main (argc=Cannot access memory at address 0x4140 ) at artsd.cc:360 (gdb) I tried emerging it with USE="-alsa", and it didn't make a difference, even the backtrace remains the same. Also, note that I'm running this from within a gnome environment (if that matters).
Lemme guess: via audio? All the previous bug reports on this seem to have been dispatched without resolution; ignored, or "disappeared", says I. This problem does not happen using Kubuntu 6.06.
(In reply to comment #1) > Lemme guess: via audio? > > All the previous bug reports on this seem to have been dispatched > without resolution; ignored, or "disappeared", says I. > > This problem does not happen using Kubuntu 6.06. > heh, switch distros, good solution. And yes, VIA 8233 in an M6811 laptop. Anyway, if I specify which pcm to use, artsd doesn't hang anymore, which is the workaround I've been using thus far.. I intended to include that in this bug.
What version of arts is this with, and is it still a problem?
Get back to us; anyway arts is broken by design and you should avoid it like plague.
(In reply to comment #4) > Get back to us; anyway arts is broken by design and you should avoid it like > plague. > I agree, seems to me that this is a horrible idea in the first place, and that software sound mixing belongs in the driver itself, with a transparent API. Anyway, it's an upstream issue, I've encountered it in Ubuntu as well, 6.10 I think.
