Bug 309853

Created attachment 75152 [details]
qdbus ... supportInformation output

Does kwin run under org.kde.kwin or some org.kde.kwin-<pid> when this happens?

After logging out and back in, I have both of them present.

Do you also have two kwin instances then?
In that case, you either
- run a multihead (not multiscreen, but two X11 servers for one user) system
- run a second KDE session
- git a kwin zombie process (which will likely consume a lot of CPU for it didn't terminate)

for the first two cases you can hook into the "multihead does not work" bug [1] (and start fixing things if you want ;-)

in the latter case, please check which is the zombie process and gdb attach to it, to check where it's hanging around instead of terminating. Then share that information and just SIGKILL (-9) it.

[1] https://bugs.kde.org/show_bug.cgi?id=256242
[2] gdb --pid <broken kwin pid here> 2>&1 | tee ~/kwin.gdb
in gdb:

bt
[enter, enter, ...]
detach
quit


info is logged in ~/kwin.gdb (surprise)

> Do you also have two kwin instances then?

No, just one.

I have two screens using xrandr (not multihead) and I shouldn't be running two KDE sessions (by that I mean I just logged in after booting, nothing special..).

Ok, and when there are both instances, does the communication with the dialog work?

(Smells like a pure issue of the KUniqueApplication "QDBusConnection: session D-Bus connection created before QCoreApplication" mumbo-jumbo failing to correctly register the service then.)

a) Would you know how to sniff dbus using eg. wireshark?
b) random guess: whenit does not work, do "qdbus | grep kwin" - how many services of "org.kde.kwin.Compositing" and "org.kde.kwin-*[0-9]*" are registered then? (my guts say that we'll have no "org.kde.kwin", one "org.kde.kwin-123456" and esp. only one "org.kde.kwin.Compositing" service then - in which case we could use the more reliably registered *.Compositing one)

> whenit does not work, do "qdbus | grep kwin" - how many
> services of "org.kde.kwin.Compositing"
none, because it's 4.9, which brings me to the question whether it can be 
reproduced in 4.10.

The communication with KWin seems to work in general, the question is what is 
going wrong and whether that could still happen in master given the 
refactoring of the Compositor.

> Ok, and when there are both instances, does the communication with the dialog work?

I'm not sure what communication you have in mind, the dialog works and responds ok as far as I can tell.

> a) Would you know how to sniff dbus using eg. wireshark?

I can use dbus-monitor or even bustle-dbus-monitor if that helps.

> b) random guess: whenit does not work, do "qdbus | grep kwin"...

As Martin pointed out, no .Compositing. Here's the output anyway:

$ qdbus | grep kwin
 org.kde.kwin
 org.kde.kwin-8264
 org.kde.kwin.Screenshot
 org.kde.kwin.Scripting

Created attachment 75164 [details]
dbus service blocker

Attached is a small program that does nothing but register a dbus service and then wait forever.

If one kills kwin, runs the blocker, runs kwin and kills the blocker one will get the behavior described in the OP.
If one does not kill the blocker, the dialog will just timeout on every dbus call.

So the only important thing to check in this regard is whether org.kde.kwin is registered when this message shows up.

PS: the blocker takes one argument being the service to block ("org.kde.kwin")

Playing commit hook

commit 59d1104d5e9a9bebf7b2207888c964b4becc2e78
Author: Thomas Lübking <thomas.luebking@gmail.com>
Date:   Sun Dec 30 00:15:30 2012 +0100

    fix dbus service registration/invocation
    
    REVIEW: 108016