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.

Sign up for GitHub

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

Jump to bottom

assertion failed: eps.windows(2).all(|w| w[0].cmp(self, &w[1]) != Ordering::Greater) #38177

Closed
jedisct1 opened this issue Dec 5, 2016 · 4 comments
Closed

assertion failed: eps.windows(2).all(|w| w[0].cmp(self, &w[1]) != Ordering::Greater) #38177

jedisct1 opened this issue Dec 5, 2016 · 4 comments
Assignees
@arielb1
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jedisct1
Copy link
Contributor

jedisct1 commented Dec 5, 2016

Got an ICE while compiling the protobuf crate with that recent snapshot: rustc 1.15.0-nightly (28d6623bc 2016-12-03) on arm.

thread 'rustc' panicked at 'assertion failed: eps.windows(2).all(|w| w[0].cmp(self, &w[1]) != Ordering::Greater)', /buildslave/rust-buildbot/slave/nightly-dist-rustc-cross-host-linux/build/src/librustc/ty/context.rs:1525

Meta

rustc --version --verbose:

rustc 1.15.0-nightly (28d6623bc 2016-12-03)
binary: rustc
commit-hash: 28d6623bccf8f7e9a40a47895df75dd9ef2619da
commit-date: 2016-12-03
host: arm-unknown-linux-gnueabihf
release: 1.15.0-nightly
LLVM version: 3.9

Backtrace: https://gist.github.com/f7ea7c27e5acb684140d2a5227621617
@sfackler sfackler added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Dec 5, 2016
@bluss bluss mentioned this issue Dec 7, 2016
Closed
scottlamb added a commit to scottlamb/moonfire-nvr that referenced this issue Dec 8, 2016
@scottlamb
stop using a couple unstable features
678500b 
It would be nice to build on stable Rust. In particular, I'm hitting
compiler bugs in Rust nightly, such at this one:
rust-lang/rust#38177
I imagine beta/stable compilers would be less problematic.

These two features were easy to get rid of:

* alloc was used to get a Box<[u8]> to uninitialized memory.
  Looks like that's possible with Vec.

* box_syntax wasn't actually used at all. (Maybe a leftover from something.)

The remaining features are:

* plugin, for clippy.
  rust-lang/rust#29597
  I could easily gate it with a "nightly" cargo feature.

* proc_macro, for serde_derive.
  rust-lang/rust#35900
  serde does support stable rust, although it's annoying.
  https://serde.rs/codegen-stable.html
  I might just wait a bit; this feature looks like it's getting close to
  stabilization.
@nikomatsakis nikomatsakis added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Dec 8, 2016
@nikomatsakis
Copy link
Contributor

triage: P-high

@rust-highfive rust-highfive added the P-high High priority label Dec 8, 2016
@pnkfelix
Copy link
Member

pnkfelix commented Dec 8, 2016

/me is super-weirded out by the fact that the panic message is claiming that the assertion is arising from within librustc/ty/context.rs; I'm pretty sure there's never been any code there that looks anything like eps.windows(2).all(|w| w[0].cmp(self, &w[1]). Is that mismatch potentially a sign of broken source span information (e.g. arising from macro expansion)?

@Badel2
Copy link
Contributor

Badel2 commented Dec 9, 2016 •
edited
Loading

I have this issue when compiling anything, even an empty project. As far as I can tell, it wasn't present in nightlies 2217bd7 2016-11-25 and 1c44857 2016-11-28

thread 'rustc' panicked at 'assertion failed: eps.windows(2).all(|w| w[0].cmp(self, &w[1]) != Ordering::Greater)', /buildslave/rust-buildbot/slave/nightly-dist-rustc-cross-host-linux/build/src/librustc/ty/context.rs:1525

I tried to run with RUST_BACKTRACE=1 and it took 10 minutes (it takes maybe 1 second without). Backtrace: https://gist.github.com/Badel2/9d0f9245fadca1505042dd4af4ef553a

root@localhost:~# rustc --version --verbose
rustc 1.15.0-nightly (daf8c1dfc 2016-12-05)
binary: rustc
commit-hash: daf8c1dfce3b448fc581cc319f64632ec22bd0e1
commit-date: 2016-12-05
host: armv7-unknown-linux-gnueabihf
release: 1.15.0-nightly
LLVM version: 3.9

Update: I tried more nightly versions and the first one to crash is rustc 1.15.0-nightly (908dba0 2016-12-01). The line number is slightly different this time.

thread 'rustc' panicked at 'assertion failed: eps.windows(2).all(|w| w[0].cmp(self, &w[1]) != Ordering::Greater)', /buildslave/rust-buildbot/slave/nightly-dist-rustc-cross-host-linux/build/src/librustc/ty/context.rs:1544

@arielb1
Copy link
Contributor

arielb1 commented Dec 9, 2016 •
edited
Loading

I can't reproduce this. What configuration are you using?

Reproduced using an armel rustc and compiling a trivial file.

@arielb1 arielb1 mentioned this issue Dec 13, 2016
Merged
@sanxiyn sanxiyn mentioned this issue Dec 15, 2016
Closed
arielb1 added a commit to arielb1/rust that referenced this issue Dec 15, 2016
@arielb1
Use StableHasher everywhere
e1d4b8f 
The standard implementations of Hasher have architecture-dependent
results when hashing integers. This causes problems when the hashes are
stored within metadata - metadata written by one host architecture can't
be read by another.

To fix that, implement an architecture-independent StableHasher and use
it in all places an architecture-independent hasher is needed.

Fixes rust-lang#38177.
bors added a commit that referenced this issue Dec 16, 2016
@bors
Auto merge of #38357 - arielb1:deterministic-hash, r=michaelwoerister
c6d8ab0 
make deterministic_hash host-architecture-independent

`DefPath::deterministic_hash` used to call `std::hash::Hash`, which depends on the current architecture in several ways, which would prevent metadata written on one host architecture from being successfully read on another one.

Use a hasher we control instead.

Fixes #38177.

r? @michaelwoerister
@alexcrichton alexcrichton mentioned this issue Dec 16, 2016
Merged
@i336 i336 mentioned this issue Jan 7, 2017
Closed
@mbrubeck mbrubeck mentioned this issue Jan 7, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@arielb1 arielb1

Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@jedisct1 @nikomatsakis @pnkfelix @sfackler @arielb1 @rust-highfive @Badel2