Closed Bug 1519862 Opened 6 years ago Closed 6 years ago

wptrunner handles content-process shutdown crashes badly

Categories

(Testing :: web-platform-tests, enhancement)

Version 3
enhancement
Not set
normal

Tracking

(firefox66 fixed)

RESOLVED FIXED
mozilla66
Tracking Status
firefox66 --- fixed

People

(Reporter: jgraham, Assigned: jgraham)

References

(Blocks 1 open bug)

Details

Attachments

(10 files)

(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details

Shutdown crashes in the content process are causing a couple of problems:

  • Tests flip between ERROR and CRASH depending on timing or whether any test causing a shutdown crash ran before them.

  • If we don't set the test status to crash then the fact that we have more PROCESS-CRASH statuses than crashing statuses causes mozharness to fail

  • Leak checking fails because the leak files end up empty which counts up as a TEST-UNEXPECTED-FAIL unless the process name is on an allow list.

Blocks: 1515043
If we get a NoSuchWindow error from marionette, then something happend that caused the window to disappear, which we can interpret as a crash. This may not be true if we accidentially navigated the window to file:// or something else that causes a remoteness change, but those are basically marionette bugs so in the long term this should be correct.
This means that if closing the windows is problematic it affects the status of the current test not the next one. Depends on D16830
This behaviour was leading to intermittent failures with shutdown crashes, as according to timing we would sometimes get a crash dump file and sometimes not (or we would sometimes get a shutdown crash and sometimes not). Until we either have the ability to allow certain crashes or the ability to set multiple expected statuses, don't change the test status when we find a process crashed (the crash will still be logged). Depends on D16831
It can happen that a tab has an expected crash in wpt. As a result we won't get a valid leak file for that content process. But this shouldn't cause the tests to fail. In the absence of a more precise mechanism we just disable that check for the tab process, but it would be an improvement to know which processes crashed and ensure that only those ended up with unexpected leak files. Depends on D16832
Instead of printing one log message per line about the fact the output was unstructured, just print one per group of unstructured lines. Depends on D16833
Sometimes it's unclear which of the errors are leading to a failure. For example wpt sometimes has PROCESS-CRASH lines that don't contribute to a failure. To make this easier to understand record the reason for the failure in the log so it appears in the summaries. Depends on D16834
For shutdown crashes in wpt wse need to ignore the crashes for now until we have a way of allowing specific ones. So just have a global flag that permits this. Depends on D16835
This works around the fact that we sometimes get an IOError trying to read a dump file on Windows. Depends on D16836
Depends on D16837
Pushed by james@hoppipolla.co.uk: https://hg.mozilla.org/integration/mozilla-inbound/rev/a1544d1ae5be Interpret the window being missing as a crash, r=ato https://hg.mozilla.org/integration/mozilla-inbound/rev/2c82daad929f Close windows after test finishes rather than before next test, r=ato https://hg.mozilla.org/integration/mozilla-inbound/rev/8d89fc8ca162 Don't set status to crash if we find a crash dump, r=ato https://hg.mozilla.org/integration/mozilla-inbound/rev/a2e2dd4e4539 Ignore missing leak files for tab process in wpt, r=ato https://hg.mozilla.org/integration/mozilla-inbound/rev/f7f763f7c5b4 Handle unstructured lines in mozlog output better in mozharness, r=ahal https://hg.mozilla.org/integration/mozilla-inbound/rev/765ec7f39243 Give mozharness output to indicate why a job failed, r=ahal https://hg.mozilla.org/integration/mozilla-inbound/rev/add585284f4e Allow ignoring process_crash in determing mozharness job status, r=ahal https://hg.mozilla.org/integration/mozilla-inbound/rev/b6e31c3bfb6e Handle case where mozcrash can't read the dump file, r=ato https://hg.mozilla.org/integration/mozilla-inbound/rev/c1a9c866d74b Improve logging for crashes, r=ato https://hg.mozilla.org/integration/mozilla-inbound/rev/3d96125d18d7 Provide a helpful error message when we get a JS Document Unloaded exception, r=ato
Assignee: nobody → james
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/15077 for changes under testing/web-platform/tests
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: