Closed Bug 1513520 Opened 1 year ago Closed 3 months ago

Intermittent devtools/server/tests/mochitest/test_framerate_04.html | More ticks should be recorded in the second batch.

Categories

(DevTools :: General, defect, P5)

defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: intermittent-bug-filer, Unassigned)

References

(Regression)

Details

(Keywords: intermittent-failure, Whiteboard: [retriggered][stockwell unknown])

Filed by: opoprus [at] mozilla.com

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

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

TEST-PASS | devtools/server/tests/mochitest/test_framerate_04.html | There should be a second batch recording available. 
09:24:05     INFO - Difference in ticks: 0
09:24:05     INFO - Buffered messages finished
09:24:05     INFO - TEST-UNEXPECTED-FAIL | devtools/server/tests/mochitest/test_framerate_04.html | More ticks should be recorded in the second batch. 
09:24:05     INFO - SimpleTest.ok@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:275:7
09:24:05     INFO - onRecordingStopped@chrome://mochitests/content/chrome/devtools/server/tests/mochitest/test_framerate_04.html:55:3
09:24:05     INFO - window.onload@chrome://mochitests/content/chrome/devtools/server/tests/mochitest/test_framerate_04.html:39:9
09:24:05     INFO - TEST-PASS | devtools/server/tests/mochitest/test_framerate_04.html | All the ticks in the first batch should be in the second batch as well. 
09:24:05     INFO - TEST-PASS | devtools/server/tests/mochitest/test_framerate_04.html | All the ticks in the final batch should be ascending in value. 
09:24:05     INFO - GECKO(5600) | MEMORY STAT | vsize 1732MB | vsizeMaxContiguous 130743099MB | residentFast 279MB | heapAllocated 114MB
09:24:05     INFO - TEST-OK | devtools/server/tests/mochitest/test_framerate_04.html | took 3164ms
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Status: REOPENED → RESOLVED
Closed: 1 year ago10 months ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Status: REOPENED → RESOLVED
Closed: 10 months ago7 months ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---

I suspect (based on the history of the failures above and from a quick look at what's being tested) that the test failure is caused by a bug elsewhere and that my patch has somehow affected timings of that test in a way that make it more likely to occur.

Although, I don't have a great understanding of what exactly this test is checking for, and if it could be related to the WR change above.

Do you know who we could ask about this test to get a better understanding of what might cause the failure? Markus, would you know anything about this test? Otherwise, I'll do some further investigation first thing Monday morning.

Flags: needinfo?(mstange)
Flags: needinfo?(gwatson)
Flags: needinfo?(apavel)

Hi Patrick, can you answer the question above regarding who might have a better understanding of this failure?

Flags: needinfo?(apavel) → needinfo?(pbrosset)

The test seems to be testing that requestAnimationFrame keeps firing after a reload(), and that the "framerate actor" (defined in devtools/server/performance/framerate.js) re-registers itself as a rAF listener when the reload navigation occurs. The test waits for 1 second between the reload() and the check. So we'd need to debug why requestAnimationFrame does not fire during that one second wait.

Flags: needinfo?(pbrosset)
Flags: needinfo?(mstange)
Status: REOPENED → RESOLVED
Closed: 7 months ago5 months ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Status: REOPENED → RESOLVED
Closed: 5 months ago3 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.