Surface synchronization: Ensure monotonically increasing IDs at activation
The crash log in 826186 suggests that the previous surface was already destroyed by the time the next activates. It's unclear how we get into this state. One possible theory is surfaces are activating out of order: 1. CompositorFrame with LocalSurfaceID 2 activates. 2. CompositorFrame with LocalSurfaceID 3 activates. 3. LocalSurfaceID 2 is marked for destruction. 4. CompositorFrame with LocalSurfaceID 2 activates again. 5. Garbage collection happens, and LocalSurfaceID 2's surface is destroyed. 6. CompositorFrame with LocalSurfaceID 4 activates, but the previous surface, LocalSurfaceId 2 has been destroyed so SetPreviousFrameSurface crashes trying to access 2. The only way to get into this state if is if there are two pending CompositorFrames for a FrameSink at once. It's unclear how this can happen because cc should not be issuing a new CompositorFrame until the previous CompositorFrame has activated. Perhaps there's a cc bug? This CL adds a diagnostic check to verify that LocalSurfaceIds activate in a monotonically increasing fashion. Bug: 826186, 672962 Change-Id: I2c3826c63d2538fa9562be683d864a11de904dd0 Reviewed-on: https://chromium-review.googlesource.com/990200 Commit-Queue: Fady Samuel <fsamuel@chromium.org> Reviewed-by:enne <enne@chromium.org> Cr-Commit-Position: refs/heads/master@{#547544}
Showing
Please register or sign in to comment