Chrome on Chrome OS is tested using a handful of frameworks, each of which you‘ll find running on Chrome’s CQ and waterfalls. If you're investigating failures in these tests, below are some tips for debugging and identifying the cause.
Tast is Chrome OS‘s integration testing framework. Since Chrome itself is instrumental to the Chrome OS system, it’s equally important that we run some of these integration tests on Chrome's waterfalls. If you find one of these tests failing (likely in the chrome_all_tast_tests
step), you can:
Inspect the failed test's log snippet: There should be a log link for each failed test with failure information. eg: For this failed build, opening the platform.Histograms log link contains stack traces and error messages.
View browser & system logs: A common cause of failure on Chrome‘s builders are browser crashes. When this happens, each test’s log snippets will simply contain warnings like “Chrome probably crashed”. To debug these crashes, navigate to the test‘s Isolated output, most likely listed in the build under the test step’s shard #0 isolated out link. From there, view the various log/chrome/...
or log/ui/...
text files and you should find some with browser crashes and stack traces.
There a couple ways to disable a test on Chrome's builders:
informational
attribute to the test‘s definition (see Tast attributes for more info). This can take time (ie: many hours) to land and propagate onto Chrome’s builders. So if you need the test disabled ASAP, consult the next option.chrome_all_tast_tests
step, add it to this list.In both cases, please make sure a bug is filed for the test, and route it to the appropriate owners.
TODO: Add instructions for debugging telemetry failures.
TODO: Add instructions for debugging GTest failures.
TODO: Add instructions for rerunning these tests locally.