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