Skip to content

Commit

Permalink
Auto merge of #8587 - ehuss:close_output-fix, r=alexcrichton
Browse files Browse the repository at this point in the history
Fix close_output test.

The close_output test was randomly failing on rust-lang/rust's CI.  This should fix the error. I ran the test in a loop on the rust-lang 16-thread CPU for 10,000 times over the course of 1.5 hours without fail.  The same stress test without this patch failed relatively easily.

I'm a bit on the fence, as this means the test is no longer testing a realistic scenario (the compiler usually doesn't emit a megabyte of diagnostics). Moving this test to a single-threaded runner should also solve the problem. I can't decide if it matters enough to bother.  WDYT?

Closes #8564
  • Loading branch information
bors committed Aug 4, 2020
2 parents 964a16a + 191250b commit 1653f35
Showing 1 changed file with 14 additions and 3 deletions.
17 changes: 14 additions & 3 deletions tests/testsuite/build.rs
Original file line number Diff line number Diff line change
Expand Up @@ -4975,11 +4975,22 @@ fn close_output() {
let mut buf = [0];
drop(socket.read_exact(&mut buf));
let use_stderr = std::env::var("__CARGO_REPRO_STDERR").is_ok();
for i in 0..10000 {
// Emit at least 1MB of data.
// Linux pipes can buffer up to 64KB.
// This test seems to be sensitive to having other threads
// calling fork. My hypothesis is that the stdout/stderr
// file descriptors are duplicated into the child process,
// and during the short window between fork and exec, the
// file descriptor is kept alive long enough for the
// build to finish. It's a half-baked theory, but this
// seems to prevent the spurious errors in CI.
// An alternative solution is to run this test in
// a single-threaded environment.
for i in 0..100000 {
if use_stderr {
eprintln!("{}", i);
eprintln!("0123456789{}", i);
} else {
println!("{}", i);
println!("0123456789{}", i);
}
}
TokenStream::new()
Expand Down

0 comments on commit 1653f35

Please sign in to comment.