[M-fis-xorig] TEST-UNEXPECTED-TIMEOUT | http://mochi.test:8888/tests/layout/style/test/test_animations_effect_timing_duration.html | application timed out after 370 seconds with no output
Categories
(Core :: Layout, defect, P5)
Tracking
()
People
(Reporter: cpeterson, Assigned: hiro)
References
Details
ahal hit this test timeout (3 out of 5 retries on "Linux 18.04 x64 WebRender opt") when trying to enable mochitest-plain in fission-xorigin mode on more platforms in bug 1694835:
INFO - TEST-START | http://mochi.test:8888/tests/layout/style/test/test_animations_effect_timing_duration.html
INFO - GECKO(31727) | JavaScript error: http://mochi.xorigin-test:8888/tests/SimpleTest/TestRunner.js, line 167: SecurityError: Permission denied to access property "wrappedJSObject" on cross-origin object
INFO - GECKO(31727) | 1616470484983 addons.xpi ERROR System addon update list error Error: got node name: html, expected: updates
INFO - Buffered messages finished
ERROR - TEST-UNEXPECTED-TIMEOUT | http://mochi.test:8888/tests/layout/style/test/test_animations_effect_timing_duration.html | application timed out after 370 seconds with no output
ERROR - Force-terminating active process(es).
|
Reporter | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 1•3 years ago
|
||
The SecurityError: Permission denied to access property "wrappedJSObject" on cross-origin object error is bug 1701777.
|
||
Comment 2•3 years ago
|
||
hiro, maybe you could take a look?
(Seems like one first step here could be to add some logging in the test, to find out how far we get before the test's progress stops & we time out.)
|
Assignee | |
Comment 3•3 years ago
|
||
I'd wait for bug 1701777.
If the timeout is caused by something animation specific, a suspicious place is this await waitForPaitns() call, but it's just waiting for a MozAfterPaint event, if we didn't receive it, it's something in WebRender..
Anyways, Chris if you still see this timeout after bug 1701777 landed, please NI to me again. Thanks!
(In reply to Daniel Holbert [:dholbert] from comment #2)
(Seems like one first step here could be to add some logging in the test, to find out how far we get before the test's progress stops & we time out.)
A pernosco session would be nicer. :)
|
|
Reporter | |
Comment 4•3 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)
I'd wait for bug 1701777.
If the timeout is caused by something animation specific, a suspicious place is this await waitForPaitns() call, but it's just waiting for a MozAfterPaint event, if we didn't receive it, it's something in WebRender..
Anyways, Chris if you still see this timeout after bug 1701777 landed, please NI to me again. Thanks!
kmag says the security error that will be fixed by bug 1701777 would not have caused this test timeout. So the test failure should be reproducible with or without bug 1701777.
|
|
Assignee | |
Comment 5•3 years ago
•
|
||
Okay, I will handle this failure. Note that when I replied comment 3, I tried to reproduce the failure locally with --run-until-failure --repeat=1000, at that time the only one failure I saw is another variant of bug 1676587, not this timeout one.
|
|
Assignee | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 6•3 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #5)
Okay, I will handle this failure. Note that when I replied comment 3, I tried to reproduce the failure locally with
--run-until-failure --repeat=1000, at that time the only one failure I saw is another variant of bug 1676587, not this timeout one.
In that case, we can probably change this bug to priority P5 and not worry about fixing it for Fission. :)
But first I just want to make sure: did you test with "xorigin" mode enabled? With or without Fission also enabled?
./mach mochitest --enable-xorigin-tests
./mach mochitest --enable-xorigin-tests --enable-fission
|
|
Assignee | |
Comment 7•3 years ago
|
||
(In reply to Chris Peterson [:cpeterson] from comment #6)
./mach mochitest --enable-xorigin-tests --enable-fission
I've been using --enable-xorigin. :/ It was in my shell history and interestingly mach command doesn't complain about it.
|
|
Reporter | |
Comment 8•3 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #7)
(In reply to Chris Peterson [:cpeterson] from comment #6)
./mach mochitest --enable-xorigin-tests --enable-fissionI've been using --enable-xorigin. :/ It was in my shell history and interestingly mach command doesn't complain about it.
I just tested mach and I think --enable-xorigin is acceptable because it is an unambiguous prefix of --enable-xorigin-tests. In contrast, mach reported an error when I tried using a bad flag like mach --enable-xorigin2.
This suggests that you ran the xorigin tests correctly and the test didn't fail locally. In that case, I will change this bug to priority P5 and you can ignore this bug for now. We will see if this test failure returns when we try to enable xorigin mochitests on Linux again (in bug 1700781).
|
|
Assignee | |
Comment 9•3 years ago
|
||
Note that I also tried this morning with "--run-until-failure --repeat=1000 --enable-webrender --enable-fission --enable-xorigin-tests" on an local opt build, it didn't fail at all. I wonder what the differences between my Ubuntu 20.04 and CI's Ubuntu 18.04 machines.
|
|
Reporter | |
Comment 10•3 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #9)
Note that I also tried this morning with "--run-until-failure --repeat=1000 --enable-webrender --enable-fission --enable-xorigin-tests" on an local opt build, it didn't fail at all. I wonder what the differences between my Ubuntu 20.04 and CI's Ubuntu 18.04 machines.
Hiro, have you had a chance to try to reproduce this xorigin test failure on Try using CI's Ubuntu 18.04 machines? Or do you think the original test failures (from comment 0) were just rare intermittent failures and we can resolve this bug as invalid? You have run this xorigin test thousands of times on your own Ubuntu 20.04 machine without any failures. :)
|
|
Assignee | |
Comment 11•3 years ago
|
||
I tried. There are still a bunch of failures, but there is no timeout on animation related tests. There are a couple of tests failed with timeout, (for example, test_bug1451199-1.html), I am not sure it's fission related or not. There are a bunch of "OMTA should work" failure, it's a sanity check whether our testing machinery for OMT animations works properly or not. I suppose it is probably caused by the reason I commented in comment 3. Anyways, filed bug 1706853 for the "OMTA should work" error.
Another high frequent failure is bug 1662625. For this failure case, we need to rewrite the test not re-use the same element for different animations.
Description
•