Version: (using KDE KDE 3.2.92) Installed from: SuSE RPMs OS: Linux After activating real-time priority (after having set chmod +s for artswrapper) for artswrapper and using sound in KDE e.g. via amaroK (but any application that uses arts works), artswrapper seems to crash the whole system on KDE_shutdown. The only remains are a black screen and the (now unusable) mousecursor. The crash is so severe, that no keyboard or mouse entries work any more, thus the system has to be shutdown hard. At first I thought, this bug was because of amaroK but I could trace it down to artswrapper. It even crashes if the system - sounds are played. Thus, playing any sound in KDE crashes the systems. It seems as if the artswrapper process is not stopped properly when leaving KDE. Perhaps the process used to "kill" artswrapper does not have sufficient permissions for that operation. Setting artswrapper back to "normal" priority fixes the problem. I have used a whole set of new configuration files for the KDE beta, so there should be no configuration errors on my system. Perhaps the permissions are not set correctly for the SuSE RPM's.
Are you by any chance using the mediacontrol kicker applet? I had this problem with 3.2.x, but it seemed to go away when I stopped using mediacontrol. However, I never had any success isolating it. Mostly because the system locks so hard that nothing in userland can run. (Though kernelspace stuff, like ICMP ping responses and the magic sysrq key, still work)
mediacontrol has absolutely nothing to do with arts.
For the record, I don't think it's mediacontrol itself, but let's see what the original submitter has to say. I only had the problem with mediacontrol + JuK and have since switched to amaroK anyway. I was merely bringing it up as a possibility, as that was one of the things that I tinkered with before the problem mysteriously disappeared. To the original submitter: what audio device are you using? (Control Panel -> Sound System -> Hardware Tab)
No, I do not use the mediacontrol applet. However, the problem first occured after changing artswrapper to real time priority while timkering around with the new KDE Beta and using programs that use arts, e.g. amaroK or noatun. If I use a program like xmms (which is running directly on alsa and not via the arts plugin) this problem does not occur. Given these premises I think it has to have to do with arts itself. I would very like to send you more detailed information about what's happening after KDE crashes, but as the computer locks me from any intervention, I cannot find out what's happening after the crash. As Hardware for arts I use ALSA on a Creative Labs Sound Blaster Live. I can absolutely reproduce the problem on my computer by resetting to real time priority for arts. Without, my system runs absolutely flawless.
I had similarly severe problems with Threaded OSS, but most went away when I flipped back to plain OSS.
There is a possibility that this bug is related to SB Live cards and the drivers in 2.4. Could we get some feedback from the ARTS developers on this? I know its going away (hopefully) in KDE 4.x, but it'd still be nice to have a bug fix for this problem before then.
Okay, just had this crash. System settings: Sound System Enabled Realtime Priority Enabled Auto-Suspend OFF Audio Device: Open Sound System Looks like the only thing it /could/ be is realtime priority. Could we PLEASE get a reply from the ARTS developers on this?
It is the real-time priority that gives artsd "the right" to crash the system. Disabling it will not fix the bug, but will make artsd crashes less fatal for the system. Also it should make it possible to produce backtraces, which will help the debugging.
[This is a crosspost to Debian Bug#266760 and KDE Bugs #88401 and #86426, plus the debian-kde mailing list.] hi all, I've been "playing" around with this bug for a couple of hours, and after some hard reboots I've made some *little* findings which I'll share hoping that people with more knowledge may find it of some utility. for completeness sake, I'll restate what is already known: - it only happens with 2.4.x kernels - it only happens if arts is running with realtime priority (which means: checkbox enabled in control center and artswrapper is setuid root) my little findings are: - there has to be a sound associated with the "KDE is exiting" event. I'm surprised this has never been mentioned; perhaps it is that I'm wrong, but if you're looking for a workaround and disabling realtime priority is not an option, having no sound with the exit event seems to do the trick. - the "culprit" of "root of all evil" seems to be kdeinit_shutdown in /usr/bin/startkde: I'd say the hang is produced when kdeinit (as per kdeinit_shutdown request) tries to shutdown an arts process that is in the middle of playback. the lines in question are: echo 'startkde: Shutting down...' 1>&2 # Clean up kdeinit_shutdown dcopserver_shutdown artsshell -q terminate adding a "sleep 10" statement just before the kdeinit_shutdown invocation seems to prevent the crash, too. that'd be because kdeinit makes arts terminate when the sound was already output. note that is effectively kdeinit who kills arts: if one takes out the "-q" from artsshell, it appears in the log: "unable to connect to sound server". I ignore if this is the expected behavior (I imagine it is), I just mention in case it may be relevant. - finally, one thing that strikes me as unusual but that may be not (and, again, I mention in case it's relevant): with the same KDE 3.3 setup, when using a 2.6 kernel there is just one artsd process per user session; with a 2.4, though, there are *two* (one being the child of the other). I haven't been able to test if this happened with KDE 3.2, but if it didn't, perhaps something weird is going in there. also, IIRC, the child process did not respond to "kill -15", "kill -9" was necessary". * * * I would ask everybody who has experienced the problem if they can check the above: (1), that having no sound associated with "KDE is exiting" prevents the crash; (2), that the "sleep 10" statement in the proper place does, too; (3), that there are two artsd processes by user session when using Linux 2.4. also, it'd be nice if someone with access to a KDE 3.2 installation could check if (3) applies. * * * and that was all this time, please excuse my verbosity. hoping some of the above may be of some help to somebody,
(1) is incorrect under KDE 3.2. I have no sound associated with KDE exit, but get this error regularly. I am using Linux 2.4.x with a SB Live! card. The error usually happens when I've left an arts-enabled media player paused for a long time and then exited it (after stopping or not makes no difference), but not always. I believe I sometimes have extra artsd processes running, but I'm not sure if this always causes the error. Executing a killall artsd before shutting off KDE prevents the error from occurring.
* Adeodato Sim
*** Bug 88401 has been marked as a duplicate of this bug. ***
I have build KDE 3.3 from the source, it's seem that i have the same bug, kdeinit_shutdown crash my system, i found a solution i killall artsd before calling the real kdeinit_shutdown and the system will not hang.
I am using kde-3.3.1 with artsd without realtime priority (artswrapper not suid) as normal user and experiment this bug... I have this bug with: -kde 3.3.1 and kde 3.3.0 -arts-1.3.0 or arts-1.3.1 What I have noticed: -It is kernel related: No problem at all with kernel 2.6.8-gentoo-r6 (and probably below). Hangs with 2.6.8-gentoo-r10, 2.6.9-gentoo, 2.6.9-gentoo-r1, 2.6.9-gentoo-r2. -Sometimes, kde hangs at startup when playing the startup sound. -Other Window Manager are working fine. -The whole system is frozen. (I tried CTRL-ALT-F1 just after clicking on logout: tty1 was at first ok, then becames frozen. I dont have another computer to try ssh, but I think it is frozen) -sysrq keys dont work. I hope it can help.
ever thought about a broken kernel?
Since my artswrapper setup is without suid, I'm probably not in the good thread. I think my trouble is a kernel problem (misconfigured or bug ?), but symptoms look very like this described here. Every thing else seems to be fine with those kernels thats why I thought it could be the same bug. I'm lost a little (no error message, dont know how to debug...) I just tried to disable artsd, and freeze occured, so it seems I'm definitively not in the good thread. Thank you however.
* Josh Metzler [Tue, 26 Oct 2004 21:51:14 -0400]: > Known workarounds: > - use kernel 2.6 > - use OSS rather than ALSA > - do not set arts to use realtime priority > - do not associate a soud with "KDE is exiting" or use a sound in WAV format (not ogg or mp3). > - add a "sleep 10" before "kdeinit_shutdown" in /usr/bin/startkde > - issue "killall artsd" from a terminal (or konsole) immediately before > shutting down.
Using OSS rather than ALSA does not work as a workaround. I still get a lockup on shutdown using OSS + realtime priority Not having a sound associated with "KDE is exiting" is not a workaround. That's the first thing I turn off, and I still get a lockup on shutdown.
*** This bug has been confirmed by popular vote. ***
The obvious work-around is to disable real-time. If you have the akode-plugin installed and a reasonably fast machine, it shouldn't be needed.
Adeodato Simó wrote: (2004-10-01 05:02) I would ask everybody who has experienced the problem if they can check the above: (1), that having no sound associated with "KDE is exiting" prevents the crash; (2), that the "sleep 10" statement in the proper place does, too; (3), that there are two artsd processes by user session when using Linux 2.4. (1) Yes, that prevents the crash (2) No, didn't help me. (3) No, just one using 2.4.27
Ok I've been suffering with the same problem and here are my findings: 1) the 'sleep 10' statement did NOT work. my computer STILL crashed 2) there is only ONE artsd process 3) setting the "Realtime priority" OFF prevents the crash 4) after a while, sound stopped working entirely, except for the "test sound" and xmms. I had to delete .kde and .kderc in ~/ to get it back. I'd still like to know why we can't use realtime priority, though.
If someone who is able reproduce the problem, could please run artsd with the debugging "-l0" turned on and report what happens during a crash (stream output to a file or something). It would help find the guilty state.
*** Bug 94644 has been marked as a duplicate of this bug. ***
Created attachment 8646 [details] Artsd Crash Log Here you can find the log of artsd when it crash the machine. See You
Just a little bit more info on this, I am using Suse 9.1, 64bit with the vaious 2.6 kernels and it is happening here as well ( SBlive 5.1) , kde 3.3.1 and now 3.3.2. So I do not think it is specifically a 2.4 kernel problem, it did not appear until I updated KDE. HTH
I just migrated from 2.4.26 --> 2.6.11 (both Gentoo) I enabled real-time priority again and I no longer have this issue after the kernel upgrade. Using ens-1371 (module).
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