You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running the cargo testsuite on a single-CPU machine hangs on jobserver::jobserver_exists.
This can also be reproduced on other machines by limiting the available CPUs, e.g. with taskset on Linux.
Steps
cargo test --test testsuite --no-run
taskset --cpu-list 0 cargo test --test testsuite -- --exact jobserver::jobserver_exists
Possible Solution(s)
That test has a build script reading CARGO_MAKEFLAGS and trying to read/write the jobserver pipes, taking and releasing a job token. I suppose in this nested invocation, all tokens must already be in use? But there's no problem when I use cargo test -j1 without restricting the taskset, so I'm not sure what's the difference.
First seen in the rpm build of 1.45.2 for RHEL 8.3.0 ppc64le while running the testsuite. Usually I get a multi-CPU builder though, so I can't say this is a new issue.
Reproduced on Fedora 32 x86_64 with cargo nightly, by limiting the CPUs with taskset as above.
The text was updated successfully, but these errors were encountered:
FWIW cargo test -j1 will build the tests themselves in single-threaded mode but that jobserver isn't inhereited by the test suite process itself, so the test suite will create its own second jobserver with the number of CPUs on the system. In any case this is a pretty easy test to fix, just need to pass -j<greater-than-one>!
Problem
Running the cargo testsuite on a single-CPU machine hangs on
jobserver::jobserver_exists
.This can also be reproduced on other machines by limiting the available CPUs, e.g. with
taskset
on Linux.Steps
cargo test --test testsuite --no-run
taskset --cpu-list 0 cargo test --test testsuite -- --exact jobserver::jobserver_exists
Possible Solution(s)
That test has a build script reading
CARGO_MAKEFLAGS
and trying to read/write the jobserver pipes, taking and releasing a job token. I suppose in this nested invocation, all tokens must already be in use? But there's no problem when I usecargo test -j1
without restricting thetaskset
, so I'm not sure what's the difference.Notes
Output of
cargo version
:First seen in the rpm build of 1.45.2 for RHEL 8.3.0 ppc64le while running the testsuite. Usually I get a multi-CPU builder though, so I can't say this is a new issue.
Reproduced on Fedora 32 x86_64 with cargo nightly, by limiting the CPUs with
taskset
as above.The text was updated successfully, but these errors were encountered: