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.

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

ICE: assertion failed: (left == right) in type_of.rs #62658

Closed
fenhl opened this issue Jul 13, 2019 · 14 comments · Fixed by #63208
Closed

ICE: assertion failed: (left == right) in type_of.rs #62658

fenhl opened this issue Jul 13, 2019 · 14 comments · Fixed by #63208
Assignees
Labels
A-async-await Area: Async & Await A-codegen Area: Code generation A-coroutines Area: Coroutines C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state 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

@fenhl
Copy link
Contributor

fenhl commented Jul 13, 2019

I just ran into this ICE:

thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `Size { raw: 404 }`,
 right: `Size { raw: 400 }`', src/librustc_codegen_llvm/type_of.rs:148:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.38.0-nightly (71f9384e3 2019-07-12) running on armv7-unknown-linux-gnueabihf

note: compiler flags: -C opt-level=3 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

https://github.com/rust-lang/rust/blob/master/src/librustc_codegen_llvm/type_of.rs#L148

I can't share the code but here are some observations:

  • The ICE occurs in debug mode as well.
  • It does not occur when running cargo check.
  • It does not occur on my MacBook (same nightly, different architecture).
@jonas-schievink jonas-schievink added A-codegen Area: Code generation C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 14, 2019
@hellow554
Copy link
Contributor

hellow554 commented Jul 15, 2019

Can you try to isolate the code, e.g. produce some code (not longer than 50 lines) that reproduces this issue?

@fenhl
Copy link
Contributor Author

fenhl commented Jul 15, 2019

I have no idea where to even start. Maybe a cargo-bisect-rustc run will help.

@hellow554
Copy link
Contributor

How big is the code? You could start by removing 'mod xxx' in your main.rs. Remove types that are not needed. Then if you only have a few files left, merge them into one and remove more things (e.g. not needed functions, structs, enums), try to replace macros with their actual content.

@fenhl
Copy link
Contributor Author

fenhl commented Jul 15, 2019

Using cargo-bisect-rustc I have determined that the ICE started to appear with 853f300 (#62407). I'll try to isolate the code now.

@jbg
Copy link

jbg commented Jul 31, 2019

i'm hitting this too, will see if i can make a small repro.

building for armv7-unknown-linux-gnueabihf target from a linux x86_64 host.

@jonas-schievink jonas-schievink added the O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state label Jul 31, 2019
@jbg
Copy link

jbg commented Jul 31, 2019

My project doesn't build for ARM even with rustc 1.37.0-nightly (088b98730 2019-07-03), which casts doubt on the above rollup merge containing the cause, I think. (Also possible that there are two similar bugs introduced at different times.) I'll try to bisect.

thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `Size { raw: 604 }`,
 right: `Size { raw: 600 }`', src/librustc_codegen_llvm/type_of.rs:148:9

@jbg
Copy link

jbg commented Jul 31, 2019

My bisect indicates the regression was introduced in 848e0a2. Armed with this clue I'm trying to figure out which part of my (giant) project is triggering it in order to make a repro.

@jonas-schievink jonas-schievink added A-coroutines Area: Coroutines E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example I-nominated regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Jul 31, 2019
@jbg
Copy link

jbg commented Jul 31, 2019

I've narrowed down the block of code that triggers the regression, and simplified it to the extent possible, but when extracted from the project it no longer causes rustc to panic. In case it's useful:

let line: Bytes = ...;
match inner.current_state {
  _ if line.starts_with(b"+CUSD: ") => {
    let mut remainder = Cursor::new(&line[9..]);
    let mut ussd_bytes: Vec<u8> = Vec::new();
    remainder.read_until(0x2c, &mut ussd_bytes)?;    //  <-----
    inner.handle_ussd().await?;
  },
  // ...
}

If the line with the arrow is commented out, the code compiles. Uncommented, it fails with:

$ cargo build --release --target armv7-unknown-linux-gnueabihf
thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `Size { raw: 604 }`,
 right: `Size { raw: 600 }`', src/librustc_codegen_llvm/type_of.rs:148:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.38.0-nightly (dddb7fca0 2019-07-30) running on x86_64-unknown-linux-gnu
note: compiler flags: -C opt-level=3 -C panic=abort -C linker=arm-linux-gnueabihf-gcc --crate-type bin

Will update if I have any success producing a standalone reproduction.

@jbg
Copy link

jbg commented Jul 31, 2019

OK, I managed to extract a standalone reproduction:

https://github.com/jbg/rust-ice-repro

@jonas-schievink jonas-schievink removed the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Jul 31, 2019
@jonas-schievink
Copy link
Contributor

cc @tmandry @matthewjasper

@jbg
Copy link

jbg commented Jul 31, 2019

I added a comment in the repo; you can make it build or fail to build by just reversing the order of two lines of code.

@jbg
Copy link

jbg commented Aug 1, 2019

I updated the repo by folding a minimised implementation of QrwLock into it rather than depending on the crate, since QrwLock seemed to be necessary to trigger the bug. In doing so I updated QrwLock to std::future and the ICE disappeared. Adding .compat().compat() to round-trip the future through a 0.1 Future brings the ICE back. (see comments in src/main.rs)

@nagisa nagisa added the P-high High priority label Aug 1, 2019
@tmandry
Copy link
Member

tmandry commented Aug 1, 2019

@rustbot claim

@tmandry
Copy link
Member

tmandry commented Aug 2, 2019

Thanks for reporting this! Fix should be landing soon.

Centril added a commit to Centril/rust that referenced this issue Aug 2, 2019
Round generator sizes to a multiple of their alignment

Fixes rust-lang#62658.

r? @cramertj
cc @eddyb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-async-await Area: Async & Await A-codegen Area: Code generation A-coroutines Area: Coroutines C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state 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
Development

Successfully merging a pull request may close this issue.

6 participants