[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kded4 lockup (which makes the desktop unusable so this is
From:       "Andreas Hartmetz" <ahartmetz () gmail ! com>
Date:       2008-05-08 16:08:42
Message-ID: f3642e6b0805080908v44529d68tef761e01758c9864 () mail ! gmail ! com
[Download RAW message or body]

2008/5/8 Andreas Hartmetz <ahartmetz@gmail.com>:
> Hi all,
>
>  yesterday I finally got around to doing some research into the
>  infamous problem that sometimes when you alt-tab the alt key would
>  "stick" and effectively make the desktop useless.
>  It seems to be caused by a completely stuck kded4. It is stuck in the
>  dirwatcher part, apparently.
>  The following output from gdb and .xsession-errors is probably
>  information enough information to find the bug for somebody who knows
>  the code involved (David maybe?).
>  Note that after I killed kded4 when I had extracted enough information
>  out of it the keyboard started to work normally again and I could
>  continue to use the desktop (I did the debugging from a different
>  machine over ssh).
>
>  I think we should also consider ways to make kded4 less brittle
>  because it's quite important. Resistance against crashes in modules
>  would be cool but also somewhat heavyweight so maybe one thread per
>  module would help? This is assuming that QDBus can work sensibly in a
>  multithreaded environment, only blocking one thread waiting for one
>  response.
>
>  Anyway, here is the debug output etc.
>
>
>  #0  0xb7fd3410 in __kernel_vsyscall ()
>  #1  0xb75ae8f3 in __write_nocancel () from
>  #/lib/tls/i686/cmov/libpthread.so.0
>  #2  0xb6b58dca in Client::writeToServer () from /usr/lib/libfam.so.0
>  #3  0xb6b5b9ef in ?? () from /usr/lib/libfam.so.0

Did you know...
FAM has been the default backend of KDirWatch for years but it was not
actually used due to a typo in an #ifdef (!!!) that was fixed four
days ago.
As a workaround for that nasty lockup I have modified KDirWatch to use
inotify as the default backend again, this time in a more obvious
manner:


Index: kdirwatch.cpp
===================================================================
--- kdirwatch.cpp       (Revision 805216)
+++ kdirwatch.cpp       (Arbeitskopie)
@@ -124,7 +124,7 @@
   m_nfsPollInterval = config.readEntry("NFSPollInterval", 5000);
   m_PollInterval = config.readEntry("PollInterval", 500);

-  QString method = config.readEntry("PreferredMethod", "Fam");
+  QString method = config.readEntry("PreferredMethod", "inotify");
   if (method == "Fam")
   {
     m_preferredMethod = Fam;


I can't believe it.
Update your kdelibs now.
I believe that we should still look for ways to make kded (way) more
robust. Strange things will happen everytime one module takes down or,
worse, locks up kded.

Cheers,
Andreas
[prev in list] [next in list] [prev in thread] [next in thread]