Issue metadata
Sign in to add a comment
|
Flaky pixel_test and trace_test timeouts on Mac Intel GPU bots |
||||||||||||||||||||||||
Issue descriptionObserved this on mac_chromium_rel_ng trybot and Mac Release (Intel) GPU.FYI bot. For mac_chromium_rel_ng these are real flakes, i.e. next build for the same CL/patchset was green. Strangely, pixel_test timeouts are only observed on the trybot, but not on GPU.FYI bot. https://ci.chromium.org/buildbot/chromium.gpu.fyi/Mac%20Release%20%28Intel%29/10227 TraceTest_WebGLGreenTriangle_AA_NoAlpha https://ci.chromium.org/buildbot/chromium.gpu.fyi/Mac%20Release%20%28Intel%29/10208 TraceTest_2DCanvasWebGL https://ci.chromium.org/buildbot/chromium.gpu.fyi/Mac%20Release%20%28Intel%29/10159 TraceTest_WebGLGreenTriangle_AA_Alpha https://ci.chromium.org/buildbot/tryserver.chromium.mac/mac_chromium_rel_ng/614398 TraceTest_2DCanvasWebGL https://ci.chromium.org/buildbot/tryserver.chromium.mac/mac_chromium_rel_ng/614409 TraceTest_WebGLGreenTriangle_NoAA_Alpha https://ci.chromium.org/buildbot/tryserver.chromium.mac/mac_chromium_rel_ng/614319 Pixel_WebGLGreenTriangle_NonChromiumImage_AA_Alpha https://ci.chromium.org/buildbot/tryserver.chromium.mac/mac_chromium_rel_ng/614351 Pixel_WebGLTransparentGreenTriangle_NoAlpha_ImplicitClear Not sure how to proceed with this, the timing out tests seem random to me, so I don't see much point in marking them flaky. Looks like this may be going on for a long time, see issue 748110. But could be a different failure mode, not enough info on that bug.
,
Dec 19 2017
The tests' specifications are in src/content/test/gpu/gpu_tests/pixel_test_pages.py , which refer to web pages in src/content/test/data/gpu/ . They are all of the form: <script src="pixel_webgl_util.js"></script> <script> var main = makeMain(true, true); </script> </head> <body onload="main()"> ... </body> So it depends on the onload handler working reliably, as well as requestAnimationFrame. It also depends on Telemetry's script_to_evaluate_on_commit feature working as expected -- the script has to be committed at just the right time, before the page's onload handler is run. There's no good reason that the WebGL tests in this directory should fail and for example the similarly structured Canvas2D tests shouldn't. Ned, Juan: are we relying on brittle / fragile primitives that are inherently racy?
,
Dec 19 2017
,
Dec 19 2017
This is how script_to_evaluate_on_commit is implemented by Telemetry: https://github.com/catapult-project/catapult/blob/e3b4c57dcbbb729558d5d41fc2154d6f6a69ceae/telemetry/telemetry/internal/backends/chrome_inspector/inspector_page.py#L49 Not sure how those primitives are then evaluated by Chrome itself, or whether there is potential for races.
,
Dec 19 2017
Pavel may know how 'Page.addScriptToEvaluateOnLoad'is implemented.
,
Dec 20 2017
Any DevTools folks still around who might be able to comment on the robustness of Page.addScriptToEvaluateOnLoad?
,
Feb 5 2018
Is this P1? If so we need an owner.
,
Feb 5 2018
I think this is likely a duplicate of Issue 797368 . We've been seeing random test failures mostly on the Mac Intel bots which are likely either a renderer process hang (on the IO thread) or a browser process hang. Need to make more changes to the Telemetry harness and probably base's child process teardown code so that we can get a symbolized minidump when this happens.
,
Jul 20
Per resolution of Issue 797368 I don't see evidence of these timeouts on the trybots any more. Duplicating this into the other bug, which has been closed as WontFix.
,
Jul 20
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by kbr@chromium.org
, Dec 19 2017