1654945 - Deadlock with out-of-process WebGL and main-process compositing

Status: RESOLVED DUPLICATE of bug 1669381

(Core :: Graphics: CanvasWebGL, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: stack traces

STR: turn on webgl.out-of-process=true and load content that tries to create a WebGL context, on a Linux debug build; I haven't seen it with an opt build yet but I haven't done much experimenting with it, and I haven't tried it on Mac yet. (Windows may be unaffected; see below.)

Sometimes it works, and sometimes the main thread blocks in sync IPC to the compositor thread (nsViewManager::Refresh → WebRenderLayerManager::FlushRendering → PCompositorBridgeChild::SendFlushRendering), while at the same time the compositor thread blocks sending a sync runnable to the main thread (HostWebGLContext::Create → gfxUtils::ThreadSafeGetFeatureStatus). I've attached the full stack traces.

With a GPU process, I think this wouldn't be a problem: the parent process main thread would block on the compositor thread, which would block on the GPU process main thread. (The GPU process was, coincidentally, turned off on Linux several hours ago in bug 1653443 due to regressions tracked in bug 1653444.)

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

The plot thickens: if I turn on the GPU process, then it crashes instead — and this seems to be 100% reproducible on both debug and opt builds on Linux — because ThreadSafeGetFeatureStatus is called with a null gfxInfo.

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #1)

I turn on the GPU process, then it crashes instead

I filed bug 1654957 for this.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jgilbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Kelsey Gilbert [:jgilbert]]

ThreadSafeGetFeatureStatus was removed in bug 1669381.