1754193 - Reusing Surface handles after GPU process crash can lead to the wrong SurfaceTexture being used

Status: NEW

(GeckoView :: General, defect, P3)

Description

[Jamie Nicol [:jnicol]]

When Surfaces/SurfaceTextures are allocated they are given a handle, which is a monotonically increasing integer value. To render Surfaces, we typically pass the Surface handle to the compositor, which then looks it up in a map to find the corresponding SurfaceTexture. Additionally, we may also have a "sync" SurfaceTexture with the same handle living in the content process (used when reading data from the Surface in the content process)

Following a GPU process crash, all the old Surfaces in the content process will be released, and the SurfaceTextures in the compositor side will have died along with the process. The "sync" SurfaceTexture may still be alive temporarily, however, until remaining references to it have been released. Additionally, the stale handle may still be held by the canvas/video code, which may attempt to render it.

When new Surfaces begin to get allocated for use in the new compositor process, we start to encounter issues as a result. Firstly, when attempting to create a new "sync" SurfaceTexture, we may find that one matching the new handle already exists as it has not been released yet. Secondly, canvas or video code may pass the stale handle to the compositor to render, which will cause the compositor to attempt to render a completely unrelated SurfaceTexture which just happens to have the same handle.

To fix this, we should namespace the handles by combining the monotonically increasing ID along with a separate ID identifying the process the SurfaceTexture was allocated in. This means looking up stale handles in the new compositor process will simply not find the SurfaceTexture. And it avoids clashing handles for sync SurfaceTextures which haven't been released yet.

Comment 1

[Chris Peterson [:cpeterson]]

Moving GPU process bugs to the new GeckoView::Sandboxing component.