Deadlock with out-of-process WebGL and main-process compositing
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
People
(Reporter: jld, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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.)
Reporter | ||
Comment 1•4 years ago
|
||
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
.
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 2•4 years ago
|
||
(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•4 years ago
|
||
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•4 years ago
|
||
ThreadSafeGetFeatureStatus was removed in bug 1669381.
Description
•