Repository navigation
Spurious (?) error in "compile-fail\rfc-2126-extern-in-paths\single-segment.rs" etc #48116
Description
First introduced by #47828 (comment).
Symptom: The following 3 test cases involving error E0432 will fail.
failures:
[compile-fail] compile-fail\rfc-2126-extern-in-paths\single-segment.rs
[compile-fail] compile-fail\use-keyword.rs
[compile-fail] compile-fail\use-mod-2.rs
Mainly affects Windows and macOS machines (maybe because they are tested first).
Current instances:
Activity
kennytm commentedon Feb 10, 2018
The second victim (#47657) contains nothing useful in the log https://ci.appveyor.com/project/rust-lang/rust/build/1.0.6293/job/k1wbokf5c59o4ghj.
cc @alexcrichton @eddyb
eddyb commentedon Feb 10, 2018
Does
compiletestreally hide ICEs now? How did this happen 😞?alexcrichton commentedon Feb 10, 2018
There's some more information as well at the top of #47828 (comment), notably that this has been seen at least once on x86_64-apple-darwin.
The fact that it's spurious yet deterministic about these three tests is pretty disturbing, and sort of points to maybe this being a nondeterministic miscompilation in librustc_resolve itself. I think it's pretty certain this was introduced via the LLVM 6 upgrade, but given the lack of ability to reproduce or anything else my preferred course of action here is:
@kennytm if this starts bouncing every other PR though we can certainly reconsider!
kennytm commentedon Feb 10, 2018
@eddyb
I've verified that the ICE is swallowed by compile-test 😢. However, even if it is not swallowed, the ICE is useless withoutRUST_BACKTRACE=1😓Edit: Wow, even worse, the test case for #48000 passed successfully even though it is still ICE-ing.check_no_compiler_crashis not effective anymore?Edit²: I think this (ICE being ignored) is caused by #47634Edit³: Nevermind, the ICE detection is functioning properly with #48048. The ICE in #48000 never failed with
--error-format json. But it specifically catches the words "error: internal compiler error".Edit⁴: The "hide ICE" thing should be fixed in #48127.
Improve debuggability of rust-lang#48116.
8 remaining items
Partially revert rust-lang#47333.
Auto merge of #48209 - kennytm:try-fix-48116, r=alexcrichton
dotdash commentedon Feb 14, 2018
The valgrind violation seems harmless. It's from
assert((getNumBuckets() & (getNumBuckets()-1)) == 0andgetNumBuckets()is:What happens here is that clang happens to ultimately put the branch on
Smallafter the branch that compares the results fromgetLargeRep()->NumBuckets. That means that the first branch may depend on uninitialized memory, because ifSmallis true, the large rep part never gets initialized.That should be fine though, because
InlineBucketsis a template parameter (8 here), and for the case thatSmallis true, the assertion could statically be proven to hold. So all you need is to check whetherSmallis true, or else whether the condition holds forgetLargeRep()->NumBuckets. So the result forNumBucketsonly matters ifSmallis false, and in that case, the memory is initialized.See also the remark under "Preparing your program" on http://valgrind.org/docs/manual/quick-start.html which says that such bogus violations are expected at higher optimization levels.
dotdash commentedon Feb 14, 2018
@alexcrichton I'm pretty sure that commit just made the jump threading pass find more opportunities to perform optimizations. So without that commit, it just never gets to hit the code path where the (bogus) violation is reported.
alexcrichton commentedon Feb 14, 2018
@dotdash gah bummer! I was wondering if it'd be something like that... (I know we have tons of those "errors" in rustc with valgrind)
If that's the case though it's sort of fascinating because it means that a binary on @eddyb's machine optimize IR differently than when it was on my machine... That still implies to me some level of undefined behavior but maybe not the kind flagged by valgrind?
alexcrichton commentedon Feb 14, 2018
@dotdash hm so fascinatingly it looks like the patch I gisted above actually does fix the compile on @eddyb's machine...
alexcrichton commentedon Feb 14, 2018
Ok some more information on this. I've finally been able to reproduce the error that @eddyb was seeing. Given the exact binaries from @eddyb I was originally unable to reproduce the issue he had on his machine. He realized, though, that our machines differed in glibc versions. Notably @eddyb had glibc 2.26 and I had glibc 2.23. Testing more versions revealed that with the binaries @eddyb gave me glibc 2.25 worked ok and glibc 2.26 was the first bad one.
With this new information I reran bisection and it fascinatingly pointed at the same commit. I truly have no idea what is going on here.
This may be a bug that only "just happens" to show up on glibc 2.26 though. The bots that are reproducing this, OSX and MinGW, are not using glibc. Still digging...
alexcrichton commentedon Feb 14, 2018
I've filed https://bugs.llvm.org/show_bug.cgi?id=36386 upstream to hopefully address this issue. I don't think we can be 100% sure that this is the exact same issue that we're seeing on OSX/Windows but I think it's as close as we're gonna get for the time being.
Diggsey commentedon Feb 14, 2018
This comment seems to hint at the same issue: https://bugs.llvm.org/show_bug.cgi?id=32981#c2
Also related to JumpThreading and non-determinism due to pointer comparisons would tally with the glibc changes (some change could result in malloc giving out chunks of memory in a different order) as well as why it affects platforms without glibc.
alexcrichton commentedon Feb 14, 2018
I'm going to preemptively close this as I believe symptom has been fixed for us with commenting out the
assumeand I think further investigation should probably be coordinated with https://bugs.llvm.org/show_bug.cgi?id=36386Auto merge of #48583 - dotdash:jt_assume, r=alexcrichton
Auto merge of #48583 - dotdash:jt_assume, r=alexcrichton