Summary: | KWin crashes if one changes compositing type fast enough | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Hrvoje Senjan <hrvoje.senjan> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | Keywords: | drkonqi |
Priority: | NOR | Flags: | thomas.luebking:
ReviewRequest+
|
Version: | git master | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
URL: | https://git.reviewboard.kde.org/r/111082/ | ||
Latest Commit: | http://commits.kde.org/kde-workspace/0b0e9ecf9f038a1c438442189a58d4dfb5ca6f96 | Version Fixed In: | 4.11 |
Attachments: | Fix? |
Description
Hrvoje Senjan
2013-06-14 22:57:54 UTC
Please note that i didn't benchmark time :-) just tried changing type just about after kwin/plasma settled with the previous one > When changing type, or graphicssystem
Changing the graphicssystem should (necessarily) restart kwin.
Do you get the same crash for that?
It might be an idea to deactivate the interface while KWin is reconfiguring. In fact that could be interesting for all KCMs. or just schedule reconfig calls inside kwin until all config has finished - should be more robust and long time fix than disabling some guis (to only forget the next one ;-) (In reply to comment #2) > Changing the graphicssystem should (necessarily) restart kwin. > Do you get the same crash for that? So far i couldn't reproduce if changing only graphicssystem. Will try to write down which combos/type trigger it most easily/how to trigger it with lowest amount of effort ;-) (In reply to comment #5) > (In reply to comment #2) > > Changing the graphicssystem should (necessarily) restart kwin. > > Do you get the same crash for that? > So far i couldn't reproduce if changing only graphicssystem. Ok, i wouldn't have expected it either. > Will try to write down which combos/type trigger no need to, we'll start concurrent reconfigures, that's all - and KConfigGroup hates any concurrent access ;-) -> see comment #4 - reconfiguration calls need to be scheduled until any current configration has finished. > no need to, we'll start concurrent reconfigures, that's all - and
> KConfigGroup hates any concurrent access ;-)
> -> see comment #4 - reconfiguration calls need to be scheduled until any
> current configration has finished.
That reminds me: the Screens::init() is called before the reading of
KConfigGroup in another thread finished and can cause issues. At least I hit a
crash a few times there when other things were broken. Didn't change yet as I
couldn't reproduce when other things were not broken.
Created attachment 80548 [details]
Fix?
Ok, as we figured KConfigGroup is not the least threadsafe - this crash is predictable then :(
For the moment Screens::create() will have to move below waitForFinished() as all other config touchers.
@Hrvoje, try to click fast with the attached simple patch ;-)
(In reply to comment #8) > @Hrvoje, try to click fast with the attached simple patch ;-) Clicked like mad, some ~15 times, didn't get a crash :-) Thanks to your rodent for its hard work ;-) Git commit 0b0e9ecf9f038a1c438442189a58d4dfb5ca6f96 by Thomas Lübking. Committed on 16/06/2013 at 11:56. Pushed by luebking into branch 'master'. move Screens::create post global config reading It calls KConfigGroup what is not thread safe and collides with threaded config reading. FIXED-IN: 4.11 REVIEW: 111082 M +5 -4 kwin/workspace.cpp http://commits.kde.org/kde-workspace/0b0e9ecf9f038a1c438442189a58d4dfb5ca6f96 |