"Linux Debug (Intel HD 530)" occasionally fails to bring up browser |
|||||||
Issue descriptionhttps://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Debug%20%28Intel%20HD%20530%29?numbuilds=200 occasionally fails to start the browser at all for some test runs. It's strange because it's 100% repeatable for that particular invocation, but previous and subsequent steps -- which are all run with exactly the same binary -- pass successfully. Attached are two logs, one from this passing run: https://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Debug%20%28Intel%20HD%20530%29/builds/1513 and one from this failing run: https://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Debug%20%28Intel%20HD%20530%29/builds/1514 Looking more deeply into the logs: one thing that's consistent across all of the attempts to bring up the browser is the port that's chosen for Telemetry's TsProxy, e.g.: --proxy-server=socks://localhost:47699 It looks like TsProxy attempts to find an ephemeral port when it starts up, so that it shouldn't collide with other services, but I still wonder whether failed attempts to bring up the browser should also restart TsProxy. Ned, do you think that's a plausible reason for these failures?
,
Apr 25 2017
Ken: I don't think there is any need for restarting ts_proxy server when the browser need to be restarted.
,
Apr 26 2017
Do you have any other guesses for why the browser would reliably hang during startup? There's a fresh user-data-dir every time. In other successful steps on the same machine, the same binaries are being used. Unless something got corrupted during the isolate extraction, which I think is very unlikely (CC'ing Swarming folks just in case), I'm not sure what other state could be being preserved causing the browser to reliably fail to start.
,
Apr 27 2017
My guess is it could be some dialog from the system that requires manual human intervention. For example, on Mac, we usually have the key chain diaglog on the bots that hang the benchmark. The best way to diagnose this type of bug is enabling screenshot capture upon failure, I think.
,
May 5 2017
,
May 5 2017
Another thing we can try here is implement system level logging to see what happened when browser failed to startup on Linux. (This method need to be implemented in linux_platform_backend: https://github.com/catapult-project/catapult/blob/master/telemetry/telemetry/internal/platform/platform_backend.py#L94)
,
May 5 2017
CL to add logging: https://codereview.chromium.org/2869483003/
,
May 7 2017
,
May 8 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 9 2018
This bot doesn't exist any more. It's been replaced by https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20FYI%20Release%20(Intel%20HD%20630) which seems more reliable. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by kbr@chromium.org
, Apr 25 2017