Skip to content

cargo panics with "timeout in poll?" error from jobserver #4643

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
durka opened this issue Oct 19, 2017 · 20 comments · Fixed by rust-lang/rust#45423
Closed

cargo panics with "timeout in poll?" error from jobserver #4643

durka opened this issue Oct 19, 2017 · 20 comments · Fixed by rust-lang/rust#45423

Comments

@durka
Copy link
Contributor

durka commented Oct 19, 2017

Here's a log trying to build clippy: https://gist.github.com/b721066be81601774e16087210ad1919

The error happens every time at a random point while building dependencies. The only way to fix it is to disable parallelism with -j 1.

This might be a bug in jobserver, or OSX itself. I'm on OSX 10.9.5.

@alexcrichton
Copy link
Member

I can't find anything on google that points to 10.9 specifically (everyone seems to claim 10.12 is broken) and all the "brokenness" appears to be in different ways? If we want to fix this we probably just want to have a fallback to select in cases like this.

@durka
Copy link
Contributor Author

durka commented Oct 19, 2017 via email

@alexcrichton
Copy link
Member

AFAIK the only "funky" thing here is that the fds are shared across multiple processes, but other than that there's not a whole lot going on here?

@ivanceras
Copy link

+1 on OSX Yosemite 10.10.3

cargo -V
cargo 0.23.0-nightly (e447ac7e9 2017-09-27)
rustc -V
rustc 1.22.0-nightly (4750c1ec0 2017-10-19)

panic error:

thread '<unnamed>' panicked at 'timeout in poll?', /Users/travis/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/jobserver-0.1.7/src/lib.rs:505:29

@alexcrichton
Copy link
Member

I'm going to hope that rust-lang/jobserver-rs@400ce8c fixes this.

@durka
Copy link
Contributor Author

durka commented Oct 20, 2017 via email

@alexcrichton
Copy link
Member

Can you compile Cargo from source? If so, can you try compiling Cargo with that patch and see if it fixes things?

@durka
Copy link
Contributor Author

durka commented Oct 20, 2017 via email

@alexcrichton
Copy link
Member

You'd probably just do something like rustup run beta path/to/target/release/cargo build and that should work ok

@durka
Copy link
Contributor Author

durka commented Oct 20, 2017 via email

@durka
Copy link
Contributor Author

durka commented Oct 20, 2017 via email

@durka
Copy link
Contributor Author

durka commented Oct 20, 2017

@alexcrichton maybe this issue is in the wrong repo now, but I can't get rustc to build with that patch.

I'm running ./x.py build -i --stage 1 src/libtest. It fails while compiling stage1 test artifacts with "timeout in poll?" Fine. I can then run ./x.py build -i --stage 1 src/libtest -j 1 to complete the build.

I edited src/Cargo.toml to override jobserver with the git repo. Now it still fails during stage1 test artifacts, but attempting to continue with -j 1 yields

Building stage1 std artifacts (x86_64-apple-darwin -> x86_64-apple-darwin)
   Compiling std_unicode v0.0.0 (file:///Users/alex/Programming/rust/rust/src/libstd_unicode)
thread '<unnamed>' panicked at 'failed to shut down worker thread', /Users/alex/.cargo/git/checkouts/jobserver-rs-27359438239da508/400ce8c/src/lib.rs:641:16
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: jobserver::imp::Helper::join
   7: <jobserver::HelperThread as core::ops::drop::Drop>::drop
   8: core::ptr::drop_in_place
   9: core::ptr::drop_in_place
error: Error during translation/LLVM phase.

error: Could not compile `std_unicode`.

@alexcrichton
Copy link
Member

Ah oops I think I botched the patch. Forgot that EINTR needs to come out as an error and not get handled. Mind testing rust-lang/jobserver-rs@b3e6165?

@durka
Copy link
Contributor Author

durka commented Oct 20, 2017 via email

@alexcrichton
Copy link
Member

Ok thanks for checking! I've pushed a new version of jobserver so all that's left is to send a PR to rust-lang/rust updating the crate

@durka
Copy link
Contributor Author

durka commented Oct 20, 2017 via email

@alexcrichton
Copy link
Member

Nah rust-lang/cargo no longer has a lockfile, and feel free to do it!

@ivanceras
Copy link

A quick question: Will this fix ship on the next version of cargo? Is doing rustup self update && rustup update on the next nightly release enough to update cargo?

bors added a commit to rust-lang/rust that referenced this issue Oct 22, 2017
update jobserver version to work around macos bug

Update `jobserver` crate to fix rust-lang/cargo#4643, a panic which can't happen according to `libc::poll`'s man page but was nevertheless reported on macOS 10.9 and 10.10.

r? @alexcrichton
@alexcrichton
Copy link
Member

@ivanceras this needed to land in rust-lang/rustc, which it now has, and now it should be in nightlies.

@ivanceras
Copy link

@alexcrichton I've just updated via rustup. The errors are now gone, it works great. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants