Skip to content
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

Timeout for running, building, linting any code #469

Closed
bjorn3 opened this issue Mar 10, 2019 · 6 comments
Closed

Timeout for running, building, linting any code #469

bjorn3 opened this issue Mar 10, 2019 · 6 comments
Labels
bug The playground isn't doing what it was intended to upstream Caused by a third-party component

Comments

@bjorn3
Copy link
Member

bjorn3 commented Mar 10, 2019

Eg:

fn main() { /*abc*/ }
   Compiling rand_os v0.1.2
   Compiling iovec v0.1.2
   Compiling num_cpus v1.10.0
   Compiling net2 v0.2.33
   Compiling memchr v2.2.0
   Compiling time v0.1.42
   Compiling rand v0.4.6
   Compiling xattr v0.2.2
   Compiling filetime v0.2.4
   Compiling atty v0.2.11
   Compiling termion v1.5.1
   Compiling MacTypes-sys v2.1.0
   Compiling memmap v0.7.0
   Compiling thread-id v3.3.0
   Compiling crossbeam-epoch v0.7.1
   Compiling crossbeam-epoch v0.3.1
   Compiling quote v0.6.11
   Compiling deflate v0.7.19
/root/entrypoint.sh: line 8:     7 Killed                  timeout --signal=KILL ${timeout} "$@"
@shepmaster shepmaster added the bug The playground isn't doing what it was intended to label Mar 10, 2019
@shepmaster
Copy link
Member

shepmaster commented Mar 10, 2019

Unsure of the root cause, although rust-lang/cargo#6720 looks like a likely candidate.

@ehuss
Copy link
Contributor

ehuss commented Mar 10, 2019

Yea, I think I have a fix. Testing with docker is a little slow.

@shepmaster
Copy link
Member

Yea, I think I have a fix. Testing with docker is a little slow.

That can be an understatement. I tend to do some heavy editing of https://github.com/integer32llc/rust-playground/blob/master/compiler/base/Cargo.toml to reduce the number of crates that are required. It also looks like the intra-stage caching is broken again, at least on Travis, so that's probably not helping either.

@shepmaster shepmaster added the upstream Caused by a third-party component label Mar 11, 2019
bors added a commit to rust-lang/cargo that referenced this issue Mar 11, 2019
Fingerprint build script deps only for path packages.

#6720 introduced some protection that if there is a build script, and two commands are used (such as `cargo build` then `cargo test`), the second command would correctly get rebuilt. However, the way it was implemented relies on mtimes working correctly. A common use case is to cache built dependencies in Docker, and Docker zeros the nanoseconds from mtime when the image is saved. This caused all packages that had build scripts to get rebuilt when the Docker image runs.

The solution here is to only use the #6720 protection for local (path) packages. This runs under the assumption that mtimes need to work for those anyways.

The consequence is that the scenario in #6720 will no longer work for detecting changes in registry dependencies with build scripts. Fixing that final edge case is nontrivial. Since it is unlikely to happen often, I figure this workaround should be sufficient for now.

cc rust-lang/rust-playground#469
cc rust-lang/rust#59061
@shepmaster shepmaster changed the title Timeout for any code Timeout for running, building, linting any code Mar 12, 2019
@moxian
Copy link

moxian commented Mar 13, 2019

I see #6734 has been merged, but the nightly playground is still timing out.
Is there another issue in play here?

@shepmaster
Copy link
Member

I see #6734 has been merged,

There are multiple steps:

  1. The fix has to be merged into the Cargo codebase (that was Fingerprint build script deps only for path packages. cargo#6734)
  2. The Cargo update needs to be merged into Rust (this is Update cargo rust#59143)
  3. Rust needs to be released (should be the next night, assuming nothing prevents the build from succeeding)

@shepmaster
Copy link
Member

Thank you, @ehuss!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The playground isn't doing what it was intended to upstream Caused by a third-party component
Projects
None yet
Development

No branches or pull requests

4 participants