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)

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.)

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.

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 &"

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.

Created attachment 70315 [details]
Output from glxinfo -l

try "qdbus org.kde.kactivitymanagerd /ActivityManager ListActivities"

if this call hangs or throws an error it's likely the "activities", try to restart kactivitymanagerd

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.

thanks - moving to kactivities

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

Is this still valid with KDE 4.8.4 or later?

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

No locks in the latest versions, everything is asynchronous now.