Bug 293104 - org.kde.kactivitymanagerd randomly unresponsive until timeout
Summary: org.kde.kactivitymanagerd randomly unresponsive until timeout
Status: RESOLVED FIXED
Alias: None
Product: kactivitymanagerd
Classification: Plasma
Component: general (show other bugs)
Version: 4.8.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Ivan Čukić
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-02 00:22 UTC by Claus Wilke
Modified: 2015-11-15 15:24 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Output from glxinfo -l (31.22 KB, text/plain)
2012-04-11 16:46 UTC, Travis Evans
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Claus Wilke 2012-02-02 00:22:56 UTC
Version:           4.8.0 (using KDE 4.8.0) 
OS:                Linux

I just updated to KDE 4.8.0 from 4.7.4. Now, every time I right-click on the window title, kwin freezes for about 20 seconds (I can move the mouse, but not do anything else). Then it recovers and everything is as before. However, it never shows the context menu it should be showing.

Reproducible: Always

Steps to Reproduce:
Right-click on window title.

Actual Results:  
kwin freezes for ~20 seconds

Expected Results:  
Context menu should show.

OS: Linux (x86_64) release 3.1.0-1.2-desktop
Compiler: gcc
Comment 1 Thomas Lübking 2012-02-02 00:30:51 UTC
does it also happen if you
a) suspend compositing (shift+alt+f12)
b) try another decoration (kcmshell4 kwindecoration)
c) try another UI style (kcmshell4 style)
Comment 2 Claus Wilke 2012-02-02 03:15:16 UTC
Switching to a different window decoration and back fixed the problem. Thanks. Probably was just some messed-up configuration from the upgrade. (I had rebooted, though.)
Comment 3 Travis Evans 2012-04-11 15:42:45 UTC
I'm just now having the same problem (Arch 64-bit, KDE 4.8). Not only does kwin freeze, but it hangs the entire X session(!) for a solid 25 seconds or more making it completely unusable in the meantime. Changing window decorations did *not* help. I tried restarting kwin, but didn't help either (in fact I got the same freeze during kwin startup, around the point where the message regarding initializing OpenGL compositing appeared, though compositing in general seems to work fine at the moment).

I don't know what triggered it; I know it worked fine before. At some point I may see if logging out and back in makes it go away, but not now since it's too much of a hassle.
Comment 4 Thomas Lübking 2012-04-11 16:09:10 UTC
a) hardware (notably GPU/driver - ideally post output of "kwin --replace" and attach "glxinfo -l"
b) does it also happen with the xrender backend?
c) as well triggered by the rmb menu?
d) the *entire* x server is "frozen"? (ie. you cannot eg. switch to VT1 and from there "DISPLAY=:0 xprop -root"?)
e) do you have multiple activities? does it remain if you remove all but one? (that's just a wild shot in the dark)
f) (esp. in case it's the rmb menu) what happens if you switch to another UI style ("kwin --replace --style plastique &")
g) do you use the raster graphicssytem? what if you "kwin --replace --graphicssystem native &"
Comment 5 Travis Evans 2012-04-11 16:45:31 UTC
a) kwin --replace gives me:
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
kwin(27145) KWin::Extensions::init: Extensions: shape: 0x "11"  composite: 0x "4"  render: 0x "b"  fixes: 0x "50"  non_native_pixmaps:  false
kwin(27145) KWin::CompositingPrefs::detect: glx version is  1 . 4
OpenGL vendor string:                   NVIDIA Corporation
OpenGL renderer string:                 GeForce GT 240/PCIe/SSE2
OpenGL version string:                  3.3.0 NVIDIA 295.20
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler
Driver:                                 NVIDIA
Driver version:                         295.20
GPU class:                              G80/G90
OpenGL version:                         3.3
GLSL version:                           3.30
X server version:                       1.11.4
Linux kernel version:                   3.2.7
Direct rendering:                       yes
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes

Will attach glxinfo -l shortly.

b) I changed it to xrender in System Settings > Desktop Effects and it does still seem to occur. In fact, I now can't switch back to OpenGL because the delay on clicking Apply is so long that I neither see nor can respond to the confirmation dialog.
c) Sorry, what's the rmb menu?
d) Yes, I can do that. So it seems X itself isn't actually frozen, it just appears that way because everything on the screen stops panting during the delay.
e) I've never used the activities feature yet, so I believe it's just one.
g) I'm not sure. I get the same effect with this kwin command, though.

Incidentally, I tried disabling compositing temporarily and got the same delay pulling up the window decoration context menu, though in this case screen updates continued (though I still could not interact with any apps during the freezup).

I also tried attaching strace -r to kwin and found that 25+ seconds seems to be spent in the call
25.023954 write(6, "\0", 1)         = 1

According to /proc, file descriptor 6 is some kind of pipe:
l-wx------ 1 ijel ijel 64 Apr 11 11:07 6 -> pipe:[47871812]

But I have no idea how to trace it any further than that.
Comment 6 Travis Evans 2012-04-11 16:46:29 UTC
Created attachment 70315 [details]
Output from glxinfo -l
Comment 7 Thomas Lübking 2012-04-11 17:07:24 UTC
try "qdbus org.kde.kactivitymanagerd /ActivityManager ListActivities"

if this call hangs or throws an error it's likely the "activities", try to restart kactivitymanagerd
Comment 8 Travis Evans 2012-04-11 18:03:18 UTC
Aha! That appears to have been the culprit. Running "qdbus org.kde.kactivitymanagerd /ActivityManager ListActivities" blocked for a long time before finally reporting:
Error: org.freedesktop.DBus.Error.NoReply
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Upon killing kactivitymanagerd and restarting it, the Kwin context menu delay is gone. The Plasma Run tool had also been mysteriously taking forever to show up, which was driving me nuts for days, and that now pops up immediately. Thanks!

Of course, I guess the issue now is what caused the activities manager to hang in the first place.
Comment 9 Thomas Lübking 2012-04-11 18:18:37 UTC
thanks - moving to kactivities
Comment 10 Thomas Lübking 2012-04-20 22:00:03 UTC
Git commit 329be7b38339d50df883c17f638af21ef9081151 by Thomas Lübking.
Committed on 12/04/2012 at 21:52.
Pushed by luebking into branch 'master'.

move sync dbus calls to kactivitymanagerd into extra thread
to prevent broken dbus chain from blocking the compositor
REVIEW: 104563

M  +9    -4    kwin/sm.cpp
M  +1    -1    kwin/toplevel.cpp
M  +1    -1    kwin/toplevel.h
M  +17   -9    kwin/useractions.cpp
M  +70   -2    kwin/workspace.cpp
M  +6    -13   kwin/workspace.h

http://commits.kde.org/kde-workspace/329be7b38339d50df883c17f638af21ef9081151
Comment 11 Myriam Schweingruber 2012-06-23 09:45:08 UTC
Is this still valid with KDE 4.8.4 or later?
Comment 12 Thomas Lübking 2012-06-23 10:17:27 UTC
The kwin part will be fixed in 4.9 (ie. we replaced the sync dbus call, far too invasive for a backport) but it's so far unknown what caused the unresponsiveness in kactivitymanagerd - i altered the title in this regard

for investigation:
the process will just life-lock, so whenever it occurs again
a) figure its pid
    ps ax | grep kactivitymanagerd  | grep -v grep

b) use gdb to get a backtrace showing the current position:
    gdb
[gdb will start]
    attach <the_pid>
[attaches to the activitymanager and loads a lot of stuff]
    bt
[prints current stack position]

post the output
Comment 13 Ivan Čukić 2015-11-15 15:24:12 UTC
No locks in the latest versions, everything is asynchronous now.