https://bugs.kde.org/show_bug.cgi?id=406784
Vlad Zahorodnii <vladz...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Latest Commit|https://commits.kde.org/kwi |https://commits.kde.org/kwi |n/c438ecbb702e970004e7e97e6 |n/d948d247fe4371462f2fe6b96 |734f57caef32ea5 |b25fd8026abafb5 --- Comment #10 from Vlad Zahorodnii <vladz...@gmail.com> --- 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 -- You are receiving this mail because: You are watching all bug changes.