Bug#266760: KDE Logout Hang because realtime artsd: a followup

2004-10-16 Thread Riku Voipio
On Fri, Oct 01, 2004 at 05:01:45AM +0200, Adeodato Simó wrote:
 [This is a crosspost to Debian Bug#266760 and KDE Bugs #88401 and #86426,
 plus the debian-kde mailing list.]

 - 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:

That would be an arts bug then, right? By adding a sleep 10
to startkde we would just be working around the bug that artsd
running on realtime priority deadlocks the system if killed
while playing back?



Bug#266760: KDE Logout Hang because realtime artsd: a followup

2004-09-30 Thread Adeodato Simó
[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...'  12

  # 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,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: Múm - Don't be afraid, you have just got your eyes closed
 
The true teacher defends his pupils against his own personal influence.
-- Amos Bronson Alcott