mirror of
https://github.com/servo/servo.git
synced 2025-09-18 19:08:22 +01:00
b685c2f424
one of the flaky failure modes we found in #38658 was that on linux, geckordp occasionally fails to connect to servoshell’s devtools server. this happens despite our preliminary connect check passing, which should imply that the devtools server is listening and ready to use. we closed the issue without any fix for that failure mode, because we were ultimately unable to reproduce it, but it still happens in the wild (#39273). we’ve now found a way to reproduce it, and we think it’s caused by a race that occurs when moving from one test to the next. for example: - test 1 finishes - we send SIGTERM to test 1’s servoshell, but it does not stop its devtools server yet - test 2 begins - we spawn test 2’s servoshell, but it does not start its devtools server yet - we try to do our preliminary connects, and it succeeds against test 1’s servoshell immediately (the failure logs on GitHub never make this clear, due to some kind of buffering problem that delays the `.` and `+` outputs) - test 1’s servoshell stops its devtools server - we try to do our actual connect, and it fails because no devtools server is listening - test 2 fails very rarely, one test’s servoshell may even fail to start its devtools server, which we think happens because the previous test’s servoshell is still listening. this has only ever happened once, and we’ve been unable to reproduce it since, but we think it’s caused by the same kind of race. for example: - test 1 finishes - we send SIGTERM to test 1’s servoshell, but it does not stop its devtools server yet - test 2 begins - we spawn test 2’s servoshell, but it does not start its devtools server yet - test 2’s servoshell tries to start its devtools server, but fails because test 1’s servoshell is still listening - test 2 fails in both cases, the failure can be explained by the fact that we send SIGTERM to the previous test’s servoshell without actually waiting for the process to exit. this patch ensures that we wait, and also moves all of the output we do in the test suite from stdout to stderr to avoid it getting mangled in GitHub Actions. Testing: see [this comment](https://github.com/servo/servo/pull/39309#issuecomment-3291007931) (before) vs [this comment](https://github.com/servo/servo/pull/39309#issuecomment-3291188997) (after) Fixes: #39273 Signed-off-by: Delan Azabani <dazabani@igalia.com> |
||
|---|---|---|
| .. | ||
| mach | ||
| servo | ||
| tidy | ||
| wpt | ||
| mach_bootstrap.py | ||
| README.md | ||
| requirements.txt | ||
This directory contains various Python modules used to support servo development.
servo
servo-specific python code e.g. implementations of mach commands. This is the canonical repository for this code.
tidy
servo-tidy is used to check licenses, line lengths, whitespace, ruff on Python files, lock file versions, and more.
wpt
servo-wpt is a module with support scripts for running, importing, exporting, updating manifests, and updating expectations for WPT tests.