RenderTask::new_mask crash on https://www.magicleap.com/creator

VERIFIED FIXED in Firefox 66

Status

()

defect
P2
critical
VERIFIED FIXED
8 months ago
4 months ago

People

(Reporter: jrmuizel, Assigned: kvark)

Tracking

(Blocks 2 bugs, {crash, regression})

Trunk
mozilla66
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox64 disabled, firefox65 disabled, firefox66 verified)

Details

(crash signature)

Attachments

(2 attachments)

No description provided.
Load the page in the title and scroll down.

This is the crash report I get: https://crash-stats.mozilla.com/report/index/7cfc4f65-8a50-4789-b2a7-69aee0181108
Priority: -- → P2
Crash Signature: [@ webrender::render_task::RenderTask::new_mask ]
Assignee: nobody → dglastonbury
dupe of 1513062 ?

latest crash: https://crash-stats.mozilla.com/report/index/92bf58ce-4d37-40b1-aa28-0b6670181213
Flags: needinfo?(bobbyholley)
Duplicate of this bug: 1513062
Same crash on https://www.magicleap.com/magic-leap-one. Both have the same regression range.
Crash Signature: [@ webrender::render_task::RenderTask::new_mask ] → [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ]
Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(bobbyholley)
Keywords: crash, regression
OS: Unspecified → All
Hardware: Unspecified → All
Version: unspecified → Trunk
Thanks for noticing the dupe :)
Crash Signature: [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ] → [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11544271950329056919 ]
Severity: normal → critical
See Also: → 1515932
I've been investigating this assert and it's related to perspective applied to an image with scaling.

Reduced testcase https://djg.github.io/wr_testcase/magickit.html
It might required clicking in the frame to trigger the assert. It doesn't always happen immediately.

I don't understand the behavior of elements with perspective applied and how pictures interact, but we shouldn't render at 90000x90000 to scale back down to 900x900. :emilio, :mattwoodrow can either of you help?
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(emilio)

The testcase appears to roughly be:

scale(1/50)
  clip(rounded-rect)
    scale(50)
      image

With the addition of perspective, to make the transforms more difficult.

The presence of the perspective means that it's hard to combine the two transforms, as we'd also have to transform the rounded rect and turn it into an arbitrary mask.

I guess that's one possible option, otherwise we probably just need to do the intermediate surface at a lower resolution (scale down to fit within a reasonable size).

Flags: needinfo?(matt.woodrow)

The test also has opacity, so the path that hits the assert in WR is setting up the processing of the PictureCompositeMode::Filter(Opacity(..)) at https://github.com/servo/webrender/blob/1b226534099a24c741e9827c4612eee1ec12d4ee/webrender/src/picture.rs#L2522.

It would be better that someone who understands picture caching to implement the correct fix for this, instead of me, so I'm unassigning myself so it can be picked up by another.

Assignee: dglastonbury → nobody
Assignee: nobody → dmalyshau
Status: NEW → ASSIGNED

There is a combination of factors in play here:

  1. a filter forces some compositor mode, which makes WR want to produce a surface for the stacking context
  2. a perspective transformation makes WR to choose the local space for rasterization
  3. a very large clip mask as an example of a render task

Produced test case (included in the crashtests with the PR):

<style>
  body {
      background-color: limegreen;
  }
  .A {
      transform: scale(0.01) perspective(1000px);
      transform-origin: 0% 0%;
      filter: grayscale(40%);
  }
  .B {
      background-color: black;
      width: 10000px;
      height: 5000px;
      border-radius: 2000px;
  }
</style>
<body>
  <div class="A">
      <div class = "B"/>
  </div>
</body>
Flags: needinfo?(emilio)

I got this issue today.

[Reproduce Steps]

  1. Restart Firefox 65.0b10
  2. Go to http://hitoki.info/
  3. Then Firefox 65.0b10 will be crashed sometimes.
Duplicate of this bug: 1515932
Crash Signature: [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11544271950329056919 ] → [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11544271950329056919 ] [@ webrender::renderer::Renderer…
Pushed by dmalyshau@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/58ebeaf27cf6
WR: Don't establish a raster root in pictures with sufficiently large local bounds r=gw
re-open of D16335, which got backed out due to Wrench test failing.
The test was failing because of different AA on a plane-splitting case, which isn't guaranteed anyway.
This revision updates the test.
Pushed by dmalyshau@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/97ae7728e243
WR: Don't establish a raster root in pictures with sufficiently large local bounds (take 2) r=jrmuizel

Re-landing now with the Wrench test adjusted: it's purpose is to check the ordering of planes in preserve-3d context. We don't guarantee AA there, so the change in result is acceptable.

Flags: needinfo?(dmalyshau)
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66

bug 1515932 was not a dupe. Removing signature.

Crash Signature: [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11544271950329056919 ] [@ webrender::renderer::Renderer… → [@ webrender::render_task::RenderTask::new_mask ] [@ webrender::render_task::RenderTask::new_picture ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.17152006278596193988 ] [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.11544271950329056919 ]
Depends on: 1521656

I have managed to crash Fx 65.0a1 buildID: 20181108220756 using the page in the title only on macOS 10.14. On Ubuntu 16.04 Fx only crashed with the link from comment 6. On Windows Fx didn't crash at all, 'best' result being the window becoming unresponsive for 2-3 seconds then returning to normal.

The issue is verified fixed using Fx 66.0b14 on macOS 10.14, Ubuntu 16.04 and Windows 10. The issues mentioned above no longer occur on the latest beta with gfx.webrender.all set to true.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.