Skip to content

/rust

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.

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

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

Comments

Assignees

@arielb1 arielb1

Labels
I-ICE P-high T-compiler regression-from-stable-to-nightly
Projects
None yet
Milestone
No milestone
7 participants
@jedisct1 @nikomatsakis @pnkfelix @Badel2 @arielb1 @sfackler @rust-highfive
@jedisct1
Copy link

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 regression-from-stable-to-nightly labels Dec 5, 2016

@bluss bluss referenced this issue Dec 7, 2016

Closed

panic compiling pkg-config #38213

scottlamb added a commit to scottlamb/moonfire-nvr that referenced this issue Dec 8, 2016

@scottlamb
stop using a couple unstable features 
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.
678500b

@nikomatsakis nikomatsakis added the T-compiler label Dec 8, 2016

@nikomatsakis

This comment has been minimized.

Sign in to view
Copy link
Contributor

nikomatsakis commented Dec 8, 2016

triage: P-high

@rust-highfive rust-highfive added the P-high label Dec 8, 2016

@nikomatsakis nikomatsakis assigned arielb1 Dec 8, 2016

@pnkfelix

This comment has been minimized.

Sign in to view
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

This comment has been minimized.

Sign in to view
Copy link
Contributor

Badel2 commented Dec 9, 2016 •
edited

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

arielb1 commented Dec 9, 2016 •
edited

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

Reproduced using an armel rustc and compiling a trivial file.

arielb1 added a commit to arielb1/rust that referenced this issue Dec 13, 2016

@arielb1
make deterministic_hash host-architecture-independent 
std:#️⃣:Hash depends on the current architecture in several ways,
which prevents metadata written on one host architecture from being
successfully read on another one.

Use a hasher we control instead.

Fixes rust-lang#38177.
0eb10a1

@arielb1 arielb1 referenced this issue Dec 13, 2016

Merged

make deterministic_hash host-architecture-independent #38357

arielb1 added a commit to arielb1/rust that referenced this issue Dec 14, 2016

@arielb1
Use StableHasher everywhere 
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.
fe4d97a

@sanxiyn sanxiyn referenced this issue Dec 15, 2016

Closed

Compiler panics on armv7 #38383

arielb1 added a commit to arielb1/rust that referenced this issue Dec 15, 2016

@arielb1
Use StableHasher everywhere 
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.
b5735fb

arielb1 added a commit to arielb1/rust that referenced this issue Dec 15, 2016

@arielb1
Use StableHasher everywhere 
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.
e1d4b8f

bors added a commit that referenced this issue Dec 16, 2016

@bors
Auto merge of #38357 - arielb1:deterministic-hash, r=michaelwoerister 
make deterministic_hash host-architecture-independent

`DefPath::deterministic_hash` used to call `std:#️⃣: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
Loading status checks…
c6d8ab0

@bors bors closed this in #38357 Dec 16, 2016

@alexcrichton alexcrichton referenced this issue Dec 16, 2016

Merged

Fix `--message-format JSON` when rustc emits non-JSON warnings #3410

@i336 i336 referenced this issue Jan 7, 2017

Closed

nightly-2016-12-16 compiling Hello World on i686: `assertion failed: eps.windows(2).all(|w| w[0].cmp(self, &w[1]) != Ordering::Greater)` #38898

@mbrubeck mbrubeck referenced this issue Jan 7, 2017

Closed

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.