Summary: | Alt-tab makes KWin crash when the window is destroyed during switch | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Stefano <steog88> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | bugseforuns, firefreu, nate |
Priority: | NOR | Keywords: | drkonqi |
Version: | 5.15.3 | Flags: | vlad.zahorodnii:
ReviewRequest+
|
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
URL: | https://phabricator.kde.org/D20916 | ||
Latest Commit: | https://commits.kde.org/kwin/d948d247fe4371462f2fe6b96b25fd8026abafb5 | Version Fixed In: | 5.16.0 |
Attachments: | screen recording |
Description
Stefano
2019-04-22 20:23:23 UTC
Do you think you could provide a screen recording? I wasted hours trying to reproduce this crash, screen recording would help me a lot. Created attachment 119573 [details]
screen recording
I am not sure it is clear. I start the export, then I focus on Kate. Then, after pressing Alt+Tab when all the windows are present to select the one that is going to disappear, I am holding only Alt until it is closed, and soon later, when I release the key after it vanished, KWin crashes.
Hope it helps.
Thanks, I've managed to reproduce the crash. Hmm, the crash occurs only when compositing is turned off. When compositing is off, unconstrained_stacking_order contains a dangling pointer (added by Workspace::restack()): Client::destroyClient(this=0x560e5f07d1a0) Workspace::addDeleted(c=0x560e5f06e3b0, orig=0x560e5f07d1a0) Workspace::raiseClient(c=0x560e5e6cc830) Workspace::lowerClient(c=0x560e5e6cc830) Workspace::lowerClient(c=0x560e5e6cc830) Workspace::restack(c=0x560e5f07d1a0, under=0x560e5e7a2510) Workspace::raiseClient(c=0x560e5e6cc830) Workspace::constrainedStackingOrder() unconstrained_stacking_order: - 0x560e5e7824a0 - 0x560e5e795eb0 - 0x560e5e7bfba0 - 0x560e5f07d1a0 - 0x560e5e7a2510 - 0x560e5e7dcf80 - 0x560e5f06e3b0 - 0x560e5e79df70 When compositing is on, KWin doesn't crash. Investigating it further. Hmm when compositing is on, the tabbox doesn't invoke Workspace::restack() if (q->isKWinCompositing()) { if (lastRaisedClient) q->elevateClient(lastRaisedClient, w, false); lastRaisedClient = currentClient; if (currentClient) q->elevateClient(currentClient, w, true); } else { if (lastRaisedClient) { q->shadeClient(lastRaisedClient, true); if (lastRaisedClientSucc) q->restack(lastRaisedClient, lastRaisedClientSucc); Yeah, this explains why. KWin/Wayland may suffer from similar problem. Git commit c438ecbb702e970004e7e97e6734f57caef32ea5 by Vlad Zagorodniy. Committed on 03/05/2019 at 18:25. Pushed by vladz into branch 'master'. Don't crash when highlighted tabbox client is closed Summary: The compositor tries to switch to the next tabbox client when currently highlighted client is closed. Though there is a small issue with that. Because the switch happens too late, a dangling pointer can be inserted into the unconstrained stacking order, which can lead to a crash later on. There are two cases: - compositing is on; - compositing is off. Compositing is on: TabBox will try to un-elevate currently highlighted client, though by that time the client no longer owns EffectWindow, so this is basically a no-op (that's why we haven't experienced this bug before). Compositing is off: TabBox will try to restack currently hightlighted client under the next tabbox client. Given that the restack method doesn't do any sanity checks(see Client::manage why), a client that is about to be destroyed will be re-inserted back into the unconstrained stacking order. This change ensures that the switch happens before currently highlighted client is removed from the stacking order. Test Plan: - Turn off compositing; - Follow steps to reproduce in the bug report (see comment 2). Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D20916 M +15 -0 client.cpp M +1 -6 workspace.cpp https://commits.kde.org/kwin/c438ecbb702e970004e7e97e6734f57caef32ea5 Git commit d948d247fe4371462f2fe6b96b25fd8026abafb5 by Vlad Zagorodniy. Committed on 15/07/2019 at 13:56. Pushed by vladz into branch 'Plasma/5.12'. Don't crash when highlighted tabbox client is closed Summary: The compositor tries to switch to the next tabbox client when currently highlighted client is closed. Though there is a small issue with that. Because the switch happens too late, a dangling pointer can be inserted into the unconstrained stacking order, which can lead to a crash later on. There are two cases: - compositing is on; - compositing is off. Compositing is on: TabBox will try to un-elevate currently highlighted client, though by that time the client no longer owns EffectWindow, so this is basically a no-op (that's why we haven't experienced this bug before). Compositing is off: TabBox will try to restack currently hightlighted client under the next tabbox client. Given that the restack method doesn't do any sanity checks(see Client::manage why), a client that is about to be destroyed will be re-inserted back into the unconstrained stacking order. This change ensures that the switch happens before currently highlighted client is removed from the stacking order. Test Plan: - Turn off compositing; - Follow steps to reproduce in the bug report (see comment 2). Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D20916 M +15 -0 client.cpp M +1 -6 workspace.cpp https://commits.kde.org/kwin/d948d247fe4371462f2fe6b96b25fd8026abafb5 *** Bug 409815 has been marked as a duplicate of this bug. *** |