Fix close_output test. #8587
Fix close_output test. #8587
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
From a "speed" perspective, do we have an idea of which is faster? I suspect the 1MB of output is faster personally, but maybe I'm wrong? We could also consider locking stdout in the loop instead of re-locking it on every iteration... |
|
Yea, this is quite a bit faster and simpler. On my system, this test takes about 3s. The alternative would mean building and linking a whole separate test. I guess another alternative would be to |
|
@bors: r+ FWIW I think the forked process theory is at least one explanation. A thread forks, holds open the file descriptor, then gets unscheduled. While it's unscheduled the entire test finishes and Cargo writes everything to a defunkt pipe, not failing. We then fail the test because Cargo didn't fail (because all output fit in the pipe buffer). There may be other bugs in play but that's at least one sure-fire way to expose this bug. |
|
📌 Commit 191250b has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Update cargo 8 commits in 2d5c2381e4e50484bf281fc1bfe19743aa9eb37a..1653f354644834073d6d2541e27fae94588e685e 2020-07-31 21:56:08 +0000 to 2020-08-04 23:14:37 +0000 - Fix close_output test. (rust-lang/cargo#8587) - clippy fixes, use matches! macro in more places (rust-lang/cargo#8575) - Display embedded man pages for built-in commands. (rust-lang/cargo#8456) - Add mdman for generating man pages. (rust-lang/cargo#8577) - Fix typo 'more then' -> 'more than' in error and comments (rust-lang/cargo#8581) - cargo login: make login message less ambiguous (rust-lang/cargo#8579) - Fix broken link in Build Cache chapter. (rust-lang/cargo#8578) - Fix intra-doc tests for renamed lint. (rust-lang/cargo#8576)
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