Closed Bug 1403035 Opened 7 years ago Closed 7 years ago

Intermittent async-scrolling/checkerboard-2-ref.html | assertion count 1 is more than expected 0 assertions from ASSERTION: Tried to delete invalid animation: 'Error'

Categories

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

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: intermittent-bug-filer, Assigned: kats)

References

Details

(Keywords: intermittent-failure, Whiteboard: [wr-mvp])

Probably a regression from bug 1402439. Based on the occurrences it looks like it only started after bug 1402439 merged to m-c so likely it interacted with some other change to cause this.
Assignee: nobody → bugmail
Blocks: 1402439
Status: NEW → ASSIGNED
Priority: P5 → P1
Whiteboard: [wr-mvp]
So far no luck reproducing this locally. I did a lot of runs of this reftest both individually and with the entire folder, with rr chaos mode.
Whiteboard: [wr-mvp]
I was able to repro on try with logging applied. Somehow we're sending a nonzero id from the content side over to the parent side for discard, and the parent doesn't know about the id. Here's the relevant snippet:

WebRenderAnimationData adding id 0x44c0000005e for discard
WRLM(0) adding 0x44c0000005e for discard
REFTEST TEST-LOAD | file:///builds/worker/workspace/build/tests/reftest/tests/layout/reftests/async-scrolling/checkerboard-2.html | 1467 / 1956 (75%)
++DOMWINDOW == 57 (0x7faacc8de000) [pid = 1100] [serial = 3518] [outer = 0x7faad07a2000]
WRLM(0) discarding animations
WRBP trying erase of id 0x44c0000005e
!!! WRBP tried to delete invalid animation 0x44c0000005e

This id (0x44c0000005e) is not referenced anywhere else in the output. So what I believe is happening is that we are creating the id at [1] because that's the only call that goes through EnsureAnimationsId without logging something. And then when the WebRenderAnimationData object associated with that frame is destroyed, it schedules the id for discard. However, the id should be getting ignored in WebRenderLayerManager::AddCompositorAnimationsIdForDiscard [2], because the id doesn't exist in mActiveCompositorAnimationIds.

I think the problem is that we're actually going into the layers-full branch at [3], which bypasses the mActiveCompositorAnimationIds check. And the reason we're going into the layers-full branch is because the reftest harness keeps flipping the layers-free pref to true at the start of each individual test and then back to false after the test. So there's opportunity for race conditions where if the WebRenderAnimationData object is destroyed in between one of the pref flips, then it will take the layers-full codepath.

Once we turn layers-free on by default and remove the "default-preferences" annotation in the reftest.list file, this problem should go away.

[1] http://searchfox.org/mozilla-central/rev/f6dc0e40b51a37c34e1683865395e72e7fca592c/layout/painting/nsDisplayList.cpp#6578
[2] https://hg.mozilla.org/mozilla-central/file/b30ae5a45536/gfx/layers/wr/WebRenderLayerManager.cpp#l1018
[3] https://hg.mozilla.org/mozilla-central/file/b30ae5a45536/gfx/layers/wr/WebRenderLayerManager.cpp#l1013
Depends on: 1389000
Whiteboard: [wr-mvp]
Whiteboard: [wr-mvp]
Hi Peter,
Do you think this bug is relatives to bug 1396471?
Flags: needinfo?(howareyou322)
See comment 4.
Flags: needinfo?(howareyou322)
And yes, this seems to have stopped after landing bug 1389000.

https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1403035&startday=2017-09-20&endday=2017-09-27&tree=trunk
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
OF shows this is down to zero.
Status: RESOLVED → VERIFIED
Whiteboard: [wr-mvp]
You need to log in before you can comment on or make changes to this bug.