Bug 309853 - KWin kcm wrongly informs that all effects failed to load
Summary: KWin kcm wrongly informs that all effects failed to load
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: 4.9.2
Platform: unspecified Linux
: NOR normal
Target Milestone: 4.10
Assignee: KWin default assignee
URL: http://forum.ubuntuusers.de/post/5197...
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-10 12:26 UTC by Martin Klapetek
Modified: 2013-01-09 07:26 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.10
mgraesslin: ReviewRequest+


Attachments
Screenshot with the bug (75.83 KB, image/png)
2012-11-10 12:26 UTC, Martin Klapetek
Details
qdbus ... supportInformation output (4.64 KB, text/plain)
2012-11-10 12:27 UTC, Martin Klapetek
Details
dbus service blocker (309 bytes, text/plain)
2012-11-11 00:16 UTC, Thomas Lübking
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Klapetek 2012-11-10 12:26:37 UTC
Created attachment 75151 [details]
Screenshot with the bug

Whenever I change any setting in KWin kcm and kwin reloads all the plugins, it lists all plugins as "could not be loaded", but all plugins are actually loaded and working. Not sure if related, but I noticed this behavior after installing nvidia 304.64 driver.

Attached is a screenshot of the kcm and also output of "qdbus ... supportInformation"

Can be reproduced everytime.
Comment 1 Martin Klapetek 2012-11-10 12:27:11 UTC
Created attachment 75152 [details]
qdbus ... supportInformation output
Comment 2 Thomas Lübking 2012-11-10 12:46:58 UTC
Does kwin run under org.kde.kwin or some org.kde.kwin-<pid> when this happens?
Comment 3 Martin Klapetek 2012-11-10 12:50:02 UTC
After logging out and back in, I have both of them present.
Comment 4 Thomas Lübking 2012-11-10 14:17:54 UTC
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)
Comment 5 Martin Klapetek 2012-11-10 14:25:22 UTC
> 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..).
Comment 6 Thomas Lübking 2012-11-10 14:36:11 UTC
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)
Comment 7 Martin Flöser 2012-11-10 14:40:26 UTC
> 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.
Comment 8 Martin Klapetek 2012-11-10 15:06:40 UTC
> 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
Comment 9 Thomas Lübking 2012-11-11 00:16:39 UTC
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.
Comment 10 Thomas Lübking 2012-11-11 00:17:15 UTC
PS: the blocker takes one argument being the service to block ("org.kde.kwin")
Comment 11 Martin Flöser 2013-01-09 07:26:00 UTC
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