Summary: | kwin crashed after modifying special window settings | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Thomas Mitterfellner <thomas> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | Keywords: | drkonqi |
Priority: | NOR | ||
Version First Reported In: | 4.11.8 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Thomas Mitterfellner
2014-05-11 18:14:02 UTC
What's the output of: kreadconfig --file kwinrc --group Style --key PluginLib try kwriteconfig --file kwinrc --group Style --key PluginLib kwin3_oxygen to prevent this. *** This bug has been marked as a duplicate of bug 321301 *** The output of kwriteconfig --file kwinrc --group Style --key PluginLib kwin3_oxygen is: kwin3_quartz Is there anything wrong with that? (I can't remember having changed the deco from the openSUSE default) The quartz deco isn't provided by KDE since quite a while and is therefore also likely not available on your system. In theory this should be no problem, the decoration should fallback to either oxygen or plastik, but for some unknown reason we occasionally get this weird bug on resolving plugin functions. -> configure it to oxygen or some other installed decoration ("kcmshell4 kwindecoration", you can also use 3rd party decorations like dekorator if you prefer a more classic look) to avoid this crash. I did kwriteconfig --file kwinrc --group Style --key PluginLib kwin3_oxygen now. Thanks for your help. > In theory this should be no problem, the decoration should fallback to
> either oxygen or plastik, but for some unknown reason we occasionally get
> this weird bug on resolving plugin functions.
This btw. should be way more robust in the upcoming KWin 5.
We had a completely failing oxygen in the neon image of last Friday (linked
against no longer existing libkdecoration.so.4.0) and KWin didn't mind that.
while I assume KPluginLoader to me more reliable than the custom functions from KDE 1 or 2 time, I doubt a mislinked lib would be a proof in this regard (as the crash is in dlsym itself) :-( My (wild) guess here is that this could simply bre related to un/loading libs and we're trying to resolve symbols of a lib that has already been unloaded at that time. |