Bug 102046

A clarification: login hangs during the "Restoring session" stage.  In .kde/share/config/ksmserverrc, I have

program1=kwin
program2=konsole
program3=kgpg
program4=kmail
program5=kwalletmanager
program6=knode
program7=kalarm
program8=kopete

and only the first 3 of these start before the login hangs.

Please attach gdb to the hung process and provide the backtrace here.

Waiting for a response.

I'm having the same problem; at least, I get hangs at login using KDE 3.4.1 with gentoo, and killing klauncher allows the login to proceed.  (Further details in the gentoo bug I filed: <http://bugs.gentoo.org/show_bug.cgi?id=99866>.)

Unfortunately, even though I have debug symbols in my KDE build, if I try to attach gdb to the hung klauncher process (I do 'ps uxaww | grep klauncher' to get the pid, 'gdb /usr/kde/3.4/bin/klauncher', then in gdb 'attach nnnn' where nnnn is the pid), I just get this:

Attaching to program: /usr/kde/3.4/bin/klauncher, process nnnn
Failed to read a valid object file image from memory.
0xXXXXXXXX in ?? ()

where 0xXXXXXXX is some random hex value.  The resulting stack trace (from 'where') is garbage (just hex values, some of which are obviously wrong, like 0x0a).

Please advise on what I can do to help track this down.

*** Bug 111921 has been marked as a duplicate of this bug. ***

l4u65v002@sneakemail.com seems to be willing to provide more information...

I have the same problem using kubuntu.  I've noticed kde will lock up if the session contains gkrellm or kontact or kopete.  I have to manually remove those applications from ~/.kde/share/config/ksmserverrc or just `rm ksmserverrc`

Yes, I'll be glad to provide more information if someone will tell me what information is needed.

Don't use "gdb <binary> ; attach <pid>" but only "gdb; attach <pid>", i.e. leave out the klauncher binary, and try again.

Created attachment 12836 [details]
Traceback from offending klauncher process

Yes, that did the trick.  Traceback from klauncher attached; if I kill this
process, kde proceeds, but only the konsole shows up (not the xemacs, kpp or
xosview that ought to show up).

Created attachment 12855 [details]
ps auxwww | grep klauncher

When klauncher stops kde at the "Restoring Session" splash, I noticed through
ps auxwww | grep klauncher that kio_file and kio_media are in the list.  So I
disabled the sound system in kde and removed all "system notification" sounds
from the Control Center and removed kmix.  Now the system starts up just fine,
and does not hang, except now there is no sound.

I narrowed it down some more.  I re-enabled the sound system and kmix then re-enabled all "system notification" sounds except for the "KDE Window Manager" sounds.  I suspect kde is restoring windows during the "restoring session" splash screen and the sound system is not able to properly generate the sounds for these windows.  I'm happy now that I don't have to
 ctrl+alt+f1,
 login,
 killall klaucher
in order to get kde to work.

> I narrowed it down some more.  I re-enabled the sound system and
> kmix then re-enabled all "system notification" sounds except for the
> "KDE Window Manager" sounds.  I suspect kde is restoring windows during
> the "restoring session" splash screen and the sound system is not able
> to properly generate the sounds for these windows.  


Confirmed here:  disabling KDE Window Manager sounds allows login to 
proceed normally.  Thanks for tracking that down.

> I'm happy now that I 
> don't have to ctrl+alt+f1,
>  login,
>  killall klaucher
> in order to get kde to work.


Got that right.

SVN commit 468171 by lunakl:

Fix a lockup between kwin and klauncher. Quite strange not many people
have noticed. KWin grabs X server, and may have knotify events during
the grab. Which may result in knotify daemon starting, and klauncher
may do X operations during that. So it hangs up waiting for X and
KWin keeps X grabbed waiting for knotifyclient call to return.
BUG: 102046



 M  +28 -2     notifications.cpp  
 M  +9 -0      notifications.h  
 M  +11 -0     utils.cpp  
 M  +1 -0      utils.h  


--- branches/KDE/3.5/kdebase/kwin/notifications.cpp #468170:468171
@@ -92,9 +92,11 @@
     return event;
     }
 
+static bool forgetIt = FALSE;
+QValueList< Notify::EventData > Notify::pending_events;
+
 bool Notify::raise( Event e, const QString& message, Client* c )
     {
-    static bool forgetIt = FALSE;
     if ( forgetIt )
         return false; // no connection was possible, don't try each time
 
@@ -102,11 +104,35 @@
     if ( !event )
         return false;
 
+// There may be a deadlock if KNotify event is sent while KWin has X grabbed.
+// If KNotify is not running, KLauncher may do X requests (startup notification, whatever)
+// that will block it. And KNotifyClient waits for the launch to succeed, which means
+// KLauncher waits for X and KWin waits for KLauncher. So postpone events in such case.
+    if( grabbedXServer())
+        {
+        EventData data;
+        data.event = event;
+        data.message = message;
+        data.window = c ? c->window() : 0;
+        pending_events.append( data );
+        return true;
+        }
+
     forgetIt= !KNotifyClient::event( c ? c->window() : 0, event, message );
-
     return !forgetIt;
     }
 
+void Notify::sendPendingEvents()
+    {
+    while( !pending_events.isEmpty())
+        {
+        EventData data = pending_events.first();
+        pending_events.pop_front();
+        if( !forgetIt )
+            forgetIt= !KNotifyClient::event( data.window, data.event, data.message );
+        }
+    }
+
 bool Notify::makeDemandAttention( Event e )
     {
     QString event = eventToName( e );
--- branches/KDE/3.5/kdebase/kwin/notifications.h #468170:468171
@@ -14,6 +14,7 @@
 
 #include <stdlib.h>
 #include <qstring.h>
+#include <qvaluelist.h>
 
 namespace KWinInternal
 {
@@ -51,8 +52,16 @@
 
         static bool raise( Event, const QString& message = QString::null, Client* c = NULL );
         static bool makeDemandAttention( Event );
+        static void sendPendingEvents();
     private:
         static QString eventToName( Event );
+        struct EventData
+            {
+            QString event;
+            QString message;
+            long window;
+            };
+        static QValueList< EventData > pending_events;
     };
 
 } // namespace
--- branches/KDE/3.5/kdebase/kwin/utils.cpp #468170:468171
@@ -30,6 +30,7 @@
 #include <X11/Xatom.h>
 
 #include "atoms.h"
+#include "notifications.h"
 
 extern Time qt_x_time;
 
@@ -282,8 +283,18 @@
     {
     assert( server_grab_count > 0 );
     if( --server_grab_count == 0 )
+        {
         XUngrabServer( qt_xdisplay());
+        XFlush( qt_xdisplay());
+        Notify::sendPendingEvents();
+        }
     }
+    
+bool grabbedXServer()
+    {
+    return server_grab_count > 0;
+    }
+
 #endif
 
 bool isLocalMachine( const QCString& host )
--- branches/KDE/3.5/kdebase/kwin/utils.h #468170:468171
@@ -188,6 +188,7 @@
 void updateXTime();
 void grabXServer();
 void ungrabXServer();
+bool grabbedXServer();
 
 // the docs say it's UrgencyHint, but it's often #defined as XUrgencyHint
 #ifndef UrgencyHint

> Fix a lockup between kwin and klauncher. Quite strange not many people
> have noticed. KWin grabs X server, and may have knotify events during
> the grab. Which may result in knotify daemon starting, and klauncher
> may do X operations during that. So it hangs up waiting for X and
> KWin keeps X grabbed waiting for knotifyclient call to return.


Thank you!  I'll look forward to the fix.

*** Bug 104408 has been marked as a duplicate of this bug. ***