Spurious failure in issue-26092 #43402
Labels
A-spurious
Area: Spurious failures in builds (spuriously == for no apparent reason)
C-tracking-issue
Category: A tracking issue for an RFC or an unstable feature.
Comments
alexcrichton
added
the
A-spurious
Mark-Simulacrum
added
the
C-tracking-issue
|
I just ran into this locally on mac, if that's relevant to anyone. |
This was referenced Sep 30, 2017
This was referenced Oct 3, 2017
|
Not sure if this is related, but nightly is now writing thread panics to stderr: whereas stable only gives: The order of the panic messages changes, so is it possible that one is being written in the middle of the 'No such file or directory'? |
aidanhs
added a commit
to aidanhs/rust
that referenced
this issue
Oct 4, 2017
Fixes rust-lang#43402 now there's no multithreaded panic printouts Also update a comment
bors
added a commit
that referenced
this issue
Oct 5, 2017
…hton Don't unwrap work item results as the panic trace is useless Fixes #43402 now there's no multithreaded panic printouts Also update a comment -------- Likely regressed in #43506, where the code was changed to panic in worker threads on error. Unwrapping gives zero extra information since the stack trace is so short, so we may as well just surface that there was an error and exit the thread properly. Because there are then no multithreaded printouts, I think it should mean the output of the test for #26199 is deterministic and not interleaved (thanks to @philipc #43402 (comment) for a hint). Sadly the output is now: ``` thread '<unnamed>' panicked at 'aborting due to worker thread panic', src/librustc_trans/back/write.rs:1643:20 note: Run with `RUST_BACKTRACE=1` for a backtrace. error: could not write output to : No such file or directory error: aborting due to previous error ``` but it's an improvement over the multi-panic situation before. r? @alexcrichton
|
I'm hoping this is fixed after the merge above. If anyone sees it again, please ping me. |
|
Ok, the error emitter itself is on a different thread. I'll see if I can figure out a fix. |
bors
added a commit
that referenced
this issue
Oct 9, 2017
…chton Don't panic in the coordinator thread, bubble up the failure Fixes #43402 (take 2) Followup to #45019, this makes the coordinator thread not panic on worker failures since they can be reported reasonably back in the main thread. The output also now has no evidence of backtraces at all, unlike the previous PR: ``` $ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc -o "" x.rs error: could not write output to : No such file or directory error: aborting due to previous error ``` r? @alexcrichton
|
Slightly more hopeful that this is fixed this time, but again - ping me if not :) |
|
Hmm, maybe need to do some testing on windows. |
|
Well this seems to be cause now (happens very intermittently): |
aidanhs
added a commit
that referenced
this issue
Oct 10, 2017
This is a big hammer, but should be effective at completely removing a few issues, including inconsistent error messages and segfaults when LLVM workers race to report results LLVM_THREAD_LOCAL has been present in LLVM since 8 months before 3.7 (the earliest supported LLVM version that Rust can use) Maybe fixes #43402 (third time lucky?)
bors
added a commit
that referenced
this issue
Oct 10, 2017
…al, r=alexcrichton Band-aid fix to stop race conditions in llvm errors This is a big hammer, but should be effective at completely removing a few issues, including inconsistent error messages and segfaults when LLVM workers race to report results `LLVM_THREAD_LOCAL` has been present in LLVM since 8 months before 3.7 (the earliest supported LLVM version that Rust can use) Maybe fixes #43402 (third time lucky?) r? @alexcrichton ------ You can see that in https://github.com/rust-lang/rust/blob/5f578dfad0dd5d43b28eff71a7e857d10c3f55fe/src/librustc_trans/back/write.rs#L75-L100 there's a small window where the static global error message (made thread local in this PR) could be altered by another thread. Note that we can't use `thread_local` because gcc 4.7 (permitted according to the readme) does not support it. Maybe ideally all the functions should be modified to not use a global, but this PR makes things deterministic at least. My only hesitation is whether errors are checked in different threads to where they occur, but I figure that's probably unlikely (and is less bad than racing code). As an aside, segfault evidence before this patch when I was doing some debugging: ``` $ while grep 'No such file or directory' log2; do RUST_LOG=debug ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc -o "" y.rs >log2 2>&1; done error: could not write output to : No such file or directory error: could not write output to : No such file or directory error: could not write output to : No such file or directory error: could not write output to : No such file or directory error: could not write output to : No such file or directory error: could not write output to : No such file or directory error: could not write output to : No such file or directory Segmentation fault (core dumped) error: could not write output to : No such file or directory error: could not write output to : No such file or directory ```
|
Another fix attempt merged (third time lucky?), same drill as usual! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Looks like:
The text was updated successfully, but these errors were encountered: