Composition recording with WebRender on macOS crashes due to calling GL methods while not having a GL context
Categories
(Core :: Performance: General, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox70 | --- | fixed |
People
(Reporter: denispal, Assigned: beth)
References
Details
Attachments
(3 files)
With webrender enabled, it doesn't seem like the composition recorder actually starts when invoking windowUtils.setCompositionRecording(1). Everything works as expected with webrender off on Mac.
Updated•6 years ago
|
Updated•6 years ago
|
Comment 1•6 years ago
|
||
On my machine, using the ctrl shift 4 shortcut (in a nightly or local build) the composition recording starts but when I stop it I crash https://crash-stats.mozilla.org/report/index/9e627659-f80e-49e0-91f8-0276e0190726
| Reporter | ||
Comment 2•6 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #1)
On my machine, using the ctrl shift 4 shortcut (in a nightly or local build) the composition recording starts but when I stop it I crash https://crash-stats.mozilla.org/report/index/9e627659-f80e-49e0-91f8-0276e0190726
I think that's because it might not actually be starting properly and the crash could be because of bug 1569258.
| Assignee | ||
Comment 3•6 years ago
|
||
(In reply to Denis Palmeiro [:denispal] from comment #2)
(In reply to Timothy Nikkel (:tnikkel) from comment #1)
On my machine, using the ctrl shift 4 shortcut (in a nightly or local build) the composition recording starts but when I stop it I crash https://crash-stats.mozilla.org/report/index/9e627659-f80e-49e0-91f8-0276e0190726
I think that's because it might not actually be starting properly and the crash could be because of bug 1569258.
That is not the case. I have applied the patch from bug 1569258 and the crash still happens.
The linked crash shows that it occurred in glBindBuffer() called from Device::map_pbo_for_readback
Attempting to bind any buffer to any value (even 0 to clear the binding) at this location seems to cause the same crash.
| Assignee | ||
Comment 4•6 years ago
|
||
This is caused by not having a current GL context when we are writing the frames to disk. Writing the frames to disk from the render thread solves the issue and also enables some cleanup of the CompositionRecorder structures.
| Assignee | ||
Updated•6 years ago
|
| Assignee | ||
Comment 5•6 years ago
|
||
On macOS, if we try to write the collected frames from the
CompositorBridgeParent we will not have an active GL context, resulting in a
crash. Writing the frames from the RenderThread solves this problem.
Depends on D39584
| Assignee | ||
Comment 6•6 years ago
|
||
Since we are not writing frames to disk from the CompositorBridgeParent in
the WebRender case, we do not actually need a handle to the
(WebRender)CompositionRecorder there. Instead, the HostLayerManager and
RenderThread can maintain exclusive handles to these objects. This will allow
us to use unique pointers for these objects and delete code in a follow up
patch.
Depends on D39789
| Assignee | ||
Comment 7•6 years ago
|
||
Now that there is only ever a single handle to the CompositionRecorder, it no
longer needs to be ref-counted. And since the WebRenderCompositionRecorder is
owned exclusively by the RenderThread, it no longer needs a mutex. All the
code that resulted from having handles to the WebRenderCompositionRecorder on
two different threads is now no longer necessary.
Depends on D39790
Comment 8•6 years ago
|
||
With these patches I get a recording now! Hooray. The pngs display upside down though.
Comment 10•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/fd6e22d00783
https://hg.mozilla.org/mozilla-central/rev/95669c21b82b
https://hg.mozilla.org/mozilla-central/rev/ffa36846d4ac
Updated•3 years ago
|
Description
•