mirror of
https://github.com/servo/servo.git
synced 2025-09-17 18:38:22 +01:00
The Servo Browser Engine
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> |
||
---|---|---|
.cargo | ||
.github | ||
.vscode | ||
components | ||
docs | ||
etc | ||
ports/servoshell | ||
python | ||
resources | ||
support | ||
tests | ||
third_party | ||
.gitattributes | ||
.gitignore | ||
.mailmap | ||
.python-version | ||
Cargo.lock | ||
Cargo.toml | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
deny.toml | ||
Info.plist | ||
LICENSE | ||
LICENSE_WHATWG_SPECS | ||
mach | ||
mach.bat | ||
PULL_REQUEST_TEMPLATE.md | ||
pyproject.toml | ||
README.md | ||
rust-toolchain.toml | ||
rustfmt.toml | ||
SECURITY.md | ||
servo-tidy.toml | ||
servobuild.example | ||
shell.nix | ||
taplo.toml | ||
uv.toml |
The Servo Parallel Browser Engine Project
Servo is a prototype web browser engine written in the Rust language. It is currently developed on 64-bit macOS, 64-bit Linux, 64-bit Windows, 64-bit OpenHarmony, and Android.
Servo welcomes contribution from everyone. Check out:
- The Servo Book for documentation
- servo.org for news and guides
Coordination of Servo development happens:
- Here in the Github Issues
- On the Servo Zulip
- In video calls advertised in the Servo Project repo.
Getting started
For more detailed build instructions, see the Servo book under Setting up your environment, Building Servo, Building for Android and Building for OpenHarmony.
macOS
- Download and install Xcode and
brew
. - Install
uv
:curl -LsSf https://astral.sh/uv/install.sh | sh
- Install
rustup
:curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
- Restart your shell to make sure
cargo
is available - Install the other dependencies:
./mach bootstrap
- Build servoshell:
./mach build
Linux
- Install
curl
:- Arch:
sudo pacman -S --needed curl
- Debian, Ubuntu:
sudo apt install curl
- Fedora:
sudo dnf install curl
- Gentoo:
sudo emerge net-misc/curl
- Arch:
- Install
uv
:curl -LsSf https://astral.sh/uv/install.sh | sh
- Install
rustup
:curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
- Restart your shell to make sure
cargo
is available - Install the other dependencies:
./mach bootstrap
- Build servoshell:
./mach build
Windows
- Download
uv
,choco
, andrustup
- Be sure to select Quick install via the Visual Studio Community installer
- In the Visual Studio Installer, ensure the following components are installed:
- Windows 10/11 SDK (anything >= 10.0.19041.0) (
Microsoft.VisualStudio.Component.Windows{10, 11}SDK.{>=19041}
) - MSVC v143 - VS 2022 C++ x64/x86 build tools (Latest) (
Microsoft.VisualStudio.Component.VC.Tools.x86.x64
) - C++ ATL for latest v143 build tools (x86 & x64) (
Microsoft.VisualStudio.Component.VC.ATL
) - C++ MFC for latest v143 build tools (x86 & x64) (
Microsoft.VisualStudio.Component.VC.ATLMFC
)
- Windows 10/11 SDK (anything >= 10.0.19041.0) (
- Restart your shell to make sure
cargo
is available - Install the other dependencies:
.\mach bootstrap
- Build servoshell:
.\mach build
Android
- Ensure that the following environment variables are set:
ANDROID_SDK_ROOT
ANDROID_NDK_ROOT
:$ANDROID_SDK_ROOT/ndk/26.2.11394342/
ANDROID_SDK_ROOT
can be any directory (such as~/android-sdk
). All of the Android build dependencies will be installed there.
- Install the latest version of the Android command-line
tools to
$ANDROID_SDK_ROOT/cmdline-tools/latest
. - Run the following command to install the necessary components:
sudo $ANDROID_SDK_ROOT/cmdline-tools/latest/bin/sdkmanager --install \ "build-tools;34.0.0" \ "emulator" \ "ndk;26.2.11394342" \ "platform-tools" \ "platforms;android-33" \ "system-images;android-33;google_apis;x86_64"
- Follow the instructions above for the platform you are building on
OpenHarmony
- Follow the instructions above for the platform you are building on to prepare the environment.
- Depending on the target distribution (e.g.
HarmonyOS NEXT
vs pureOpenHarmony
) the build configuration will differ slightly. - Ensure that the following environment variables are set
DEVECO_SDK_HOME
(Required when targetingHarmonyOS NEXT
)OHOS_BASE_SDK_HOME
(Required when targetingOpenHarmony
)OHOS_SDK_NATIVE
(e.g.${DEVECO_SDK_HOME}/default/openharmony/native
or${OHOS_BASE_SDK_HOME}/${API_VERSION}/native
)SERVO_OHOS_SIGNING_CONFIG
: Path to json file containing a valid signing configuration for the demo app.
- Review the detailed instructions at Building for OpenHarmony.
- The target distribution can be modified by passing
--flavor=<default|harmonyos>
tomach <build|package|install>
.