Closed Bug 1421825 Opened 7 years ago Closed 6 years ago

"Assertion failure: GetApzc()->GetParent() == aParent" on 1430589-1.html crashtest with WebRender enabled

Categories

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

Product:
Core
Component:
Graphics: WebRender
Platform:
x86_64
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla63
Tracking Flags:
Tracking Status
firefox63 --- fixed

People

(Reporter: botond, Assigned: kats)

References

(Blocks 1 open bug)

Details

(Whiteboard: [wr-reserve])

Attachments

(3 files)

Stack trace
(deleted), text/plain
Details
Display list dump
(deleted), text/plain
Details
Bug 1421825 - Fix crash and re-enable crashtest.
(deleted), text/x-review-board-request
jrmuizel
: review+
Details
Attached file Stack trace (deleted) —
STR: 1. Enable WebRender in a debug build. I'm running on Linux and had to force-enable hardware acceleration as well. 2. Load http://codepen.io/Matori/full/BoaZeV/ 3. Scroll down a couple of slides That triggers the following assertion failure: Assertion failure: GetApzc()->GetParent() == aParent, at /home/botond/dev/projects/mozilla/central/gfx/layers/apz/src/HitTestingTreeNode.cpp:398 Stack trace is attached. I also get a crapton of the following warning; not sure whether it's related: WARN:webrender::prim_store: invalid primitive rect TypedRect(0×0 at (0,0))
Attached file Display list dump (deleted) —
Markus, in this display list dump, the fixed-pos display item 0x7f52e40e9a20 has asr(<0x7f52e5ffe1e0>) while it's containing wraplist items have asr(<0x7f52e61d21e0>, <0x7f52e5ffe1e0>). Doesn't this violate the base truths that you laid out at https://mozilla.logbot.info/gfx/20170726#c309399 ? It seems to me that if the wraplist can scroll infinitely far using asr 0x7f52e61d21e0 but the fixed item inside doesn't scroll with it, then the wraplist shouldn't have finite bounds. Or am I missing something?
Flags: needinfo?(mstange)
Whiteboard: [wr-mvp] [triage]
Priority: -- → P3
Whiteboard: [wr-mvp] [triage] → [wr-reserve]
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1) > It seems to me that if the wraplist can scroll infinitely far using asr > 0x7f52e61d21e0 but the fixed item inside doesn't scroll with it, then the > wraplist shouldn't have finite bounds. Unless the fixed item is clipped with a scrolled clip. Then that clip would ensure finite bounds of the fixed item with respect to the scrolled ASR, and thus finite bounds for the wraplist. The fixed item here is generated by background-attachment: fixed. Fixed backgrounds usually have a scrolled clip: the background clip region. I'm a bit surprised that the fixed item in this display list only has a fixed clip and no scrolled clip. I think that's the source of this bug.
Flags: needinfo?(mstange)
(In reply to Markus Stange [:mstange] from comment #2) > Unless the fixed item is clipped with a scrolled clip. Then that clip would > ensure finite bounds of the fixed item with respect to the scrolled ASR, and > thus finite bounds for the wraplist. Ah, that makes sense. Thanks! > The fixed item here is generated by background-attachment: fixed. Fixed > backgrounds usually have a scrolled clip: the background clip region. I'm a > bit surprised that the fixed item in this display list only has a fixed clip > and no scrolled clip. I think that's the source of this bug. The fixed item does seem to have a clip that's scrolled by 0x7f52e61d21e0, which is the "scrolling" ASR on the parent wraplist. So I think this is what you were expecting, if I understand correctly. I probably just didn't handle this case properly in the WR code.
Oh, I see.
I'll look into fixing this. I understand the problem now although not really sure what the best fix is.
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
Priority: P3 → P1
Note that turning on gfx.webrender.hit-test makes this crash go away, and I was hoping we could just do that rather than having to fix this explicitly.
Depends on: 1421380
gfx.webrender.hit-test is on by default (for WR) now, so closing this.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
This assertion failure actually can still get triggered on WR builds. The 1430589-1.html crashtest is an example that triggers it (that crashtest is currently disabled for this reason). Here's a recent try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=193e663bec6c81d6564e6f4c43de13258d0793e4 where I tried enabling it and it still fails. I'm reopening this bug since no patch landed here, and we can reuse this for fixing the root cause. Plus the crashtest.list file still refers to this bug.
Blocks: webrender-testing
Status: RESOLVED → REOPENED
OS: Linux → All
Priority: P1 → P2
Resolution: FIXED → ---
Summary: "Assertion failure: GetApzc()->GetParent() == aParent" on specific page with WebRender enable → "Assertion failure: GetApzc()->GetParent() == aParent" on 1430589-1.html crashtest with WebRender enabled
Comment on attachment 8991010 [details] Bug 1421825 - Fix crash and re-enable crashtest. https://reviewboard.mozilla.org/r/256016/#review262958
Attachment #8991010 - Flags: review?(jmuizelaar) → review+
Pushed by kgupta@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2052715b9faf Fix crash and re-enable crashtest. r=jrmuizel
https://hg.mozilla.org/mozilla-central/rev/2052715b9faf
Status: REOPENED → RESOLVED
Closed: 7 years ago → 6 years ago
status-firefox63: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: