Merge lp:~compiz-team/compiz/compiz.fix_1088399 into lp:compiz/0.9.9
Status: | Merged |
---|---|
Approved by: | Brandon Schaefer |
Approved revision: | 3526 |
Merged at revision: | 3606 |
Proposed branch: | lp:~compiz-team/compiz/compiz.fix_1088399 |
Merge into: | lp:compiz/0.9.9 |
Diff against target: |
1016 lines (+412/-127) 9 files modified
include/core/window.h (+6/-1) src/event.cpp (+33/-4) src/option/tests/CMakeLists.txt (+1/-0) src/option/tests/option.cpp (+4/-0) src/outputdevices.h (+5/-0) src/privatewindow.h (+38/-29) src/tests/CMakeLists.txt (+1/-0) src/window.cpp (+244/-93) tests/system/xorg-gtest/tests/compiz_xorg_gtest_test_window_stacking.cpp (+80/-0) |
To merge this branch: | bzr merge lp:~compiz-team/compiz/compiz.fix_1088399 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
PS Jenkins bot (community) | continuous-integration | Approve | |
Marco Trevisan (Treviño) | Pending | ||
Brandon Schaefer | Pending | ||
Review via email: mp+147838@code.launchpad.net |
This proposal supersedes a proposal from 2012-12-10.
Commit message
Ensure that we never get a BadWindow due to the sibling in a ConfigureWindow.
Issuing a ConfigureWindow request with a sibling parameter that refers
to a sibling that's actually destroyed server side results in a BadWindow
error, and causes what we might think is a correct ConfigureWindow request
to fail. This would cause even more problems because we had marked
the request as succeeding, and adjusted serverWindows appropriately,
which would cause further restacks to rely on the invalid internal state.
Unfortunately, this is effectively a race condition between the client and
the server. We receive our events and are racing the server to not
destroy the window internally before we get a chance to issue a
ConfigureWindow request relative to the destroyed window.
Because of that, we need to hold a server grab during the period in which
we check if the sibling window is still valid server side and when
we issue a ConfigureWindow request. If it is valid, then we can guaruntee
that the server will process the request relative to the sibling window,
and if not, we can select another sibling as appropriate.
Adjusted the API such that any function which looks for an appropriate sibling
or any function which calls XConfigureWindow with the sibling parameter
set requires a server grab to be active (by virtue of the fact that they
accept a const ServerLock &).
The only implicit contract between clients now is that the client must
obtain the sibling window either by using one of the designated functions
to do so which requires a ServerLock, or that the client holds a server lock
and while it holds the ServerLock, it calls XGetWindowAttri
XGetGeometry to check if the sibling window is valid.
configureXWindow was split into configureXWindow and
restackAndConfi
will warn about this potential race condition if you attempt to
restack a window using it.
Passing tests:
[ RUN ] CompizXorgSyste
[ OK ] CompizXorgSyste
(LP: #1088399)
Description of the change
Ensure that we never get a BadWindow due to the sibling in a ConfigureWindow.
Issuing a ConfigureWindow request with a sibling parameter that refers
to a sibling that's actually destroyed server side results in a BadWindow
error, and causes what we might think is a correct ConfigureWindow request
to fail. This would cause even more problems because we had marked
the request as succeeding, and adjusted serverWindows appropriately,
which would cause further restacks to rely on the invalid internal state.
Unfortunately, this is effectively a race condition between the client and
the server. We receive our events and are racing the server to not
destroy the window internally before we get a chance to issue a
ConfigureWindow request relative to the destroyed window.
Because of that, we need to hold a server grab during the period in which
we check if the sibling window is still valid server side and when
we issue a ConfigureWindow request. If it is valid, then we can guaruntee
that the server will process the request relative to the sibling window,
and if not, we can select another sibling as appropriate.
Adjusted the API such that any function which looks for an appropriate sibling
or any function which calls XConfigureWindow with the sibling parameter
set requires a server grab to be active (by virtue of the fact that they
accept a const ServerLock &).
The only implicit contract between clients now is that the client must
obtain the sibling window either by using one of the designated functions
to do so which requires a ServerLock, or that the client holds a server lock
and while it holds the ServerLock, it calls XGetWindowAttri
XGetGeometry to check if the sibling window is valid.
configureXWindow was split into configureXWindow and
restackAndConfi
will warn about this potential race condition if you attempt to
restack a window using it.
Passing tests:
[ RUN ] CompizXorgSyste
[ OK ] CompizXorgSyste
(LP: #1088399)
LGTM