Closed Bug 1505934 Opened 7 years ago Closed 7 years ago

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

Categories

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

Product:
Core
Component:
Graphics: WebRender
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla66
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox64 --- disabled
firefox65 --- disabled
firefox66 --- verified

People

(Reporter: jrmuizel, Assigned: kvark)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(2 files)

WR: Don't establish a raster root in pictures with sufficiently large local bounds
47 bytes, text/x-phabricator-request
Details | Review
WR: Don't establish a raster root in pictures with sufficiently large local bounds (take 2)
47 bytes, text/x-phabricator-request
Details | Review
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 ]
Blocks: stage-wr-trains
Assignee: nobody → dglastonbury
dupe of 1513062 ? latest crash: https://crash-stats.mozilla.com/report/index/92bf58ce-4d37-40b1-aa28-0b6670181213
Flags: needinfo?(bobbyholley)
Same crash on https://www.magicleap.com/magic-leap-one. Both have the same regression range.
Blocks: wr-stability, 1490242
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
status-firefox64: --- → disabled
status-firefox65: --- → disabled
status-firefox66: --- → affected
status-firefox-esr60: --- → unaffected
Flags: needinfo?(bobbyholley)
Keywords: crash, regression
OS: Unspecified → All
Hardware: Unspecified → All
See Also: → https://github.com/servo/webrender/issues/3406
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.
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)

https://hg.mozilla.org/mozilla-central/rev/97ae7728e243

Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox66: affected → fixed
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 ]

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
status-firefox66: fixed → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: