Errors about _GetDevToolsClient

[Ian Barkley-Yeung]

I was trying to run

tools/perf/run_benchmark system_health.common_desktop --browser-executable=out/Release/chrome --reset-results --results-label="Version 1"

 on my Linux machine, and it's failing with 

(ERROR) 2021-02-03 21:17:05,975 chrome_browser_backend.BindDevToolsClient:133  Timed out while waiting 60s for _GetDevToolsClient.
Traceback (most recent call last):
  File "/ssd/iby/chromium/src/third_party/catapult/telemetry/telemetry/internal/backends/chrome/chrome_browser_backend.py", line 130, in BindDevToolsClient
    timeout=self.browser_options.browser_startup_timeout)
  File "/ssd/iby/chromium/src/third_party/catapult/common/py_utils/py_utils/__init__.py", line 150, in WaitFor
    (timeout, GetConditionString()))
TimeoutException: Timed out while waiting 60s for _GetDevToolsClient.

Chrome then crashes with a SIGABRT.

There's nothing in the docs about this. Any ideas what I might do? 

Thanks

[John Chen]

This error means that Telemetry was unable to connect to Chrome for some reason. When you run your test, do you see a new Chrome window opening? If you see a new Chrome window, please navigate to chrome://version, and check that the Command Line includes --remote-debugging-port=0, and the value given in --user-data-dir matches the value of Profile Path. If you don't see a new Chrome window, there might be something wrong with your Chrome build.

[Ian Barkley-Yeung]

I see a very brief flash, nothing more.

If I run out/Release/chrome directly, it works fine.

[John Chen]

A brief flash of Chrome usually indicates that Chrome crashed soon after startup. Since running out/Release/chrome directly works fine, this might be due to some command line switches added by Telemetry. By adding -v switch to run_benchmark command line, you can see all the Chrome command line switches used by Telemetry (it's a very long list), and try to run Chrome manually with those switches.

Another sanity check you can try is to use --browser=system-chrome, to see if Telemetry works correctly with a known-good version of Chrome.

[Ian Barkley-Yeung]

If I run the binary with the command lines args, I get

libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)

DevTools listening on ws://127.0.0.1:43701/devtools/browser/df89da05-24d0-44c2-8add-227d64df93f8
[3061206:3061206:0217/173929.227108:ERROR:viz_main_impl.cc(150)] Exiting GPU process due to errors during initialization
[3061271:3061271:0217/173929.262728:ERROR:vaapi_wrapper.cc(604)] Could not get a valid VA display
[3061271:3061271:0217/173929.262958:ERROR:gpu_init.cc(426)] Passthrough is not supported, GL is egl
[3061174:3061174:0217/173929.372025:FATAL:viz_process_transport_factory.cc(315)] Software compositing fallback is unavailable. Goodbye.

This is on a remote desktop session.

Any ideas what the issue might be?

[John Chen]

It looks like you don't have a supported GPU. Normally, Chrome would just fall back to work without GPU. However, for consistent results, Telemetry requires the presence of GPU. See https://source.chromium.org/chromium/chromium/src/+/master:third_party/catapult/telemetry/telemetry/internal/browser/browser_options.py?q=assert-gpu-compositing.

To work around, you can edit the above code locally to remove --assert-gpu-compositing option, though some measurements will be affected by it.

[Ian Barkley-Yeung]

That didn't quite work, but going into tools/perf/benchmarks/system_health.py and replacing 

   def SetExtraBrowserOptions(self, options):
     # Using the software fallback can skew the rendering related metrics. So
     # disable that.
    options.AppendExtraBrowserArgs('--disable-software-compositing-fallback')

with

   def SetExtraBrowserOptions(self, options):

      pass

fixed the issue. Thanks for the pointers!

[John Chen]

Thanks for the update. Sorry that my pointer was a little off, but glad that you figured it out.