Closed Bug 1462980 Opened 2 years ago Closed Last year

Intermittent gfx/layers/apz/test/mochitest/test_bug982141.html | found the RCD node

Categories

(Core :: Panning and Zooming, defect, P5)

defect

Tracking

()

RESOLVED FIXED
mozilla64
Tracking Status
firefox64 --- fixed

People

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

References

Details

Attachments

(1 file)

Filed by: rgurzau [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=179406283&repo=mozilla-central

https://queue.taskcluster.net/v1/task/XnZV9nmiRgSYNLL5X5dnQg/runs/0/artifacts/public/logs/live_backing.log

13:03:18     INFO -  1198 INFO TEST-OK | gfx/layers/apz/test/mochitest/test_bug1304689.html | took 225ms
13:03:18     INFO -  1199 INFO TEST-START | gfx/layers/apz/test/mochitest/test_bug982141.html
13:03:18     INFO -  TEST-INFO | started process screenshot
13:03:18     INFO -  TEST-INFO | screenshot: exit 0
13:03:18     INFO -  Buffered messages logged at 13:03:18
13:03:18     INFO -  1200 INFO TEST-PASS | gfx/layers/apz/test/mochitest/test_bug982141.html | expected at least one paint in compositor test data
13:03:18     INFO -  Buffered messages finished
13:03:18    ERROR -  1201 INFO TEST-UNEXPECTED-FAIL | gfx/layers/apz/test/mochitest/test_bug982141.html | found the RCD node
Frequency of intermittent seemed to be more frequent with WR on Linux.
I'll take a look.
Assignee: nobody → kats
I wasn't able to reproduce this locally (didn't try super-hard either) but just from looking at the test, it uses ad-hoc code to wait for the paints to be flushed. This predates all the newfangled things we have, and we should update the test to use the newfangled things that are more robust.

More specifically, I suspect what is happening here is that the test in helper_bug982141.html runs immediately after isMozAfterPaintPending gets cleared, and requests the compositor APZ test data. However with WR there is more chance that the transaction is still in-flight (stuck in the updater queue waiting for the scene build to happen, for instance) and so the compositor APZ test data query comes back empty. If we add a flushApzRepaints or something that does a round-trip through the updater thread that should fix this.
Pushed by kgupta@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ba86672c033d
Use the more robust waitUntilApzStable instead of ad-hoc afterPaint waiting. r=botond
https://hg.mozilla.org/mozilla-central/rev/ba86672c033d
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
To stop this bug from getting starred more. If there are more failures they should go in a new bug.
You need to log in before you can comment on or make changes to this bug.