Closed Bug 1588484 Opened 5 years ago Closed 4 years ago

Crash in [@ mozilla::layers::ContainerLayerMLGPU::FindVisibleBounds]

Categories

(Core :: Graphics: Layers, defect, P2)

Unspecified
Windows 10
defect

Tracking

()

RESOLVED FIXED
mozilla72
Fission Milestone M5
Tracking Status
firefox-esr68 --- unaffected
firefox71 --- wontfix
firefox72 --- fixed

People

(Reporter: Gabi, Assigned: mattwoodrow)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

Attached image crash.gif

This bug is for crash report bp-45377dff-3a67-448f-a941-7e1b80191014.

Top 10 frames of crashing thread:

0 xul.dll static class mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> > mozilla::layers::ContainerLayerMLGPU::FindVisibleBounds gfx/layers/mlgpu/ContainerLayerMLGPU.cpp:110
1 xul.dll static class mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> > mozilla::layers::ContainerLayerMLGPU::FindVisibleBounds gfx/layers/mlgpu/ContainerLayerMLGPU.cpp:132
2 xul.dll static class mozilla::Maybe<mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> > mozilla::layers::ContainerLayerMLGPU::FindVisibleBounds gfx/layers/mlgpu/ContainerLayerMLGPU.cpp:132
3 xul.dll void mozilla::layers::ContainerLayerMLGPU::ComputeIntermediateSurfaceBounds gfx/layers/mlgpu/ContainerLayerMLGPU.cpp:162
4 xul.dll bool mozilla::layers::FrameBuilder::Build gfx/layers/mlgpu/FrameBuilder.cpp:69
5 xul.dll void mozilla::layers::LayerManagerMLGPU::RenderLayers gfx/layers/mlgpu/LayerManagerMLGPU.cpp:373
6 xul.dll void mozilla::layers::LayerManagerMLGPU::Composite gfx/layers/mlgpu/LayerManagerMLGPU.cpp:327
7 xul.dll void mozilla::layers::LayerManagerMLGPU::EndTransaction gfx/layers/mlgpu/LayerManagerMLGPU.cpp:276
8 xul.dll void mozilla::layers::CompositorBridgeParent::CompositeToTarget gfx/layers/ipc/CompositorBridgeParent.cpp:1028
9 xul.dll mozilla::layers::CompositorVsyncScheduler::Composite gfx/layers/ipc/CompositorVsyncScheduler.cpp:250

  • Steps to Reproduce:
  1. Launch Firefox
  2. Set fission.autostart to true
  3. Go to reddit.com
  4. Restart browser using browser console
  5. Go to reddit.com tab after restart
  6. Repeat steps 4. and 5.
  • Expected Result: No crashes, issues are encountered
  • Actual Result: Browser crash in Crash in [@ mozilla::layers::ContainerLayerMLGPU::FindVisibleBounds]
Component: Document Navigation → Graphics: Layers
Assignee: nobody → jmuizelaar
Blocks: 1573569

The priority flag is not set for this bug.
:jbonisteel, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jbonisteel)

Hey Matt - any suggestions about this one?

Flags: needinfo?(jbonisteel) → needinfo?(matt.woodrow)
Priority: -- → P3
Fission Milestone: --- → M5
Priority: P3 → P2

So it looks like Advanced Layers has RefLayerMLGPU as an entirely separate implementation from ContainerLayerMLGPU, and only supports intermediate surfaces on normal ContainerLayers.

Without fission, RefLayers are only used for tabs, and this was a safe assumption. With fission they can be used for iframes, and nested arbitrarily, so they really need to be treated the same as normal ContainerLayers.

I think we'll need to share all the implementation code between RefLayerMLGPU and ContainerLayerMLGPU (similar to what we do for ContainerLayerComposite), and calls to AsContainerLayerMLGPU() need to return a common interface (or be replaced with something else).

Jessie, does anyone on Graphics have time to fix up Advanced Layers for fission?

Flags: needinfo?(matt.woodrow) → needinfo?(jbonisteel)

Chatted with Matt about this on Slack - we are going to make a patch to disable AL with Fission for now to unblock dogfooding and then make a call later once WR Everywhere and Fission timelines are more clear to see if we will still need to do this or not.

Flags: needinfo?(jbonisteel)
Assignee: jmuizelaar → matt.woodrow
Pushed by mwoodrow@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6339a731c30d
Disable Advanced Layers for now when using fission for the window. r=kmag
Pushed by mwoodrow@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2d0db7ddd092
Disable Advanced Layers for now when using fission for the window. r=kmag
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
Flags: needinfo?(matt.woodrow)
Regressions: 1606316

Matt, you added the layers.advanced.fission.enabled pref in this bug to disable Advanced Layers "for now" when using Fission. Is there another bug to fix and re-enable Advanced Layers for Fission? Do we need to fix Advanced Layers before we ship Fission?

Flags: needinfo?(matt.woodrow)

There's not a bug filed, since at the time the plan was to never support Fission+non-WebRender.

We've tried to disable Advanced Layers in the past and ran into correctness issues with D3D11 layers. We would need to fix those, or this bug before we could ship Fission to release without WebRender.

Flags: needinfo?(matt.woodrow)
Depends on: 1664334

(In reply to Matt Woodrow (:mattwoodrow) from comment #12)

There's not a bug filed, since at the time the plan was to never support Fission+non-WebRender.

We've tried to disable Advanced Layers in the past and ran into correctness issues with D3D11 layers. We would need to fix those, or this bug before we could ship Fission to release without WebRender.

Thanks. I filed bug 1664334 to track the Fission team's investigation of whether we need to fix those D3D11 Advanced Layers issues or not. We have been assuming we should require WebRender for Fission, but given the uncertainty about SW-WR's schedule to support the ~40% of Windows users that don't have WebRender-compatible hardware, we are re-evaluating whether we should support Fission without WebRender on Windows. (We are already assuming Fission will ship with or without WebRender on macOS and Linux.)

Where does the "~40% of Windows users that don't have WebRender-compatible hardware" number come from?

Flags: needinfo?(cpeterson)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #14)

Where does the "~40% of Windows users that don't have WebRender-compatible hardware" number come from?

I was wrong. After talking with Jim Mathies, the correct percentage is more like 10% (Release channel users stuck with basic compositor instead of D3D11 according to [1]). I think the "40%" number came from the number of users still on Windows 7 or 8 (about 30% of Windows Firefox users), which don't support WebRender yet.

Windows 7 and 8 not supporting WebRender will still be a potential blocker for rolling out Fission to those users.

[1] https://sql.telemetry.mozilla.org/dashboard/web-render-rollout-tracking

Flags: needinfo?(cpeterson)

(In reply to Chris Peterson [:cpeterson] from comment #15)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #14)

Where does the "~40% of Windows users that don't have WebRender-compatible hardware" number come from?

I was wrong. After talking with Jim Mathies, the correct percentage is more like 10% (Release channel users stuck with basic compositor instead of D3D11 according to [1]). I think the "40%" number came from the number of users still on Windows 7 or 8 (about 30% of Windows Firefox users), which don't support WebRender yet.

Windows 7 and 8 not supporting WebRender will still be a potential blocker for rolling out Fission to those users.

Win7 is scheduled to get WebRender in 83. I've been on parental leave so haven't been following the Fission schedule, is it valuable to try to push that to 82 to avoid blocking Fission?

Flags: needinfo?(cpeterson)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #16)

Windows 7 and 8 not supporting WebRender will still be a potential blocker for rolling out Fission to those users.

Win7 is scheduled to get WebRender in 83. I've been on parental leave so haven't been following the Fission schedule, is it valuable to try to push that to 82 to avoid blocking Fission?

Awesome. No need to rush Win7 for 82!

Flags: needinfo?(cpeterson) → needinfo?(jmuizelaar)
Flags: needinfo?(jmuizelaar)
You need to log in before you can comment on or make changes to this bug.