ICE: index out of bounds: the len is 7 but the index is 7

[jfrimmel]

I encountered an ICE today. Below you find the backtrace of running cargo test. I ran cargo clean afterwards and the ICE vanished, so it seams to be connected to incremental compilation.

thread 'rustc' panicked at 'index out of bounds: the len is 7 but the index is 7', /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/slice/mod.rs:2695:10
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   6: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:381
   7: rust_begin_unwind
             at src/libstd/panicking.rs:308
   8: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   9: core::panicking::panic_bounds_check
             at src/libcore/panicking.rs:61
  10: <rustc::ty::query::on_disk_cache::CacheDecoder as serialize::serialize::SpecializedDecoder<syntax_pos::span_encoding::Span>>::specialized_decode
  11: serialize::serialize::Decoder::read_struct
  12: serialize::serialize::Decoder::read_seq
  13: serialize::serialize::Decoder::read_struct
  14: serialize::serialize::Decoder::read_seq
  15: <rustc::mir::Mir as serialize::serialize::Decodable>::decode::{{closure}}
  16: rustc::ty::query::on_disk_cache::OnDiskCache::try_load_query_result
  17: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  18: rustc_mir::monomorphize::collector::collect_items_rec
  19: rustc_mir::monomorphize::collector::collect_items_rec
  20: rustc_mir::monomorphize::collector::collect_crate_mono_items::{{closure}}
  21: rustc::util::common::time
  22: rustc_mir::monomorphize::collector::collect_crate_mono_items
  23: rustc::util::common::time
  24: rustc_mir::monomorphize::partitioning::collect_and_partition_mono_items
  25: rustc::ty::query::__query_compute::collect_and_partition_mono_items
  26: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::collect_and_partition_mono_items>::compute
  27: rustc::dep_graph::graph::DepGraph::with_task_impl
  28: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  29: rustc_codegen_ssa::base::codegen_crate
  30: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::codegen_crate
  31: rustc::util::common::time
  32: rustc_interface::passes::start_codegen
  33: rustc::ty::context::tls::enter_global
  34: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  35: rustc_interface::passes::create_global_ctxt::{{closure}}
  36: rustc_interface::passes::BoxedGlobalCtxt::enter
  37: rustc_interface::queries::Query<T>::compute
  38: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::ongoing_codegen
  39: rustc_interface::interface::run_compiler_in_existing_thread_pool
  40: std::thread::local::LocalKey<T>::with
  41: scoped_tls::ScopedKey<T>::set
  42: syntax::with_globals
query stack during panic:
#0 [optimized_mir] processing `metadata::tests::sample_metadata_can_be_deserialized::{{closure}}#0`
#1 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack

error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https:/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.36.0 (a53f9df32 2019-07-03) running on x86_64-unknown-linux-gnu
note: compiler flags: -C debuginfo=2 -C incremental
note: some of the compiler flags provided by cargo are hidden

If required I can attach the full project including the build directories, as I zipped it after the ICE.

[Centril]

If required I can attach the full project including the build directories, as I zipped it after the ICE.

If possible, we would most of all appreciate a reproducer that works on the playground (this will facilitate fixing the bug faster) but if that's not possible a link to the zip would be good also.

[jfrimmel]

If required I can attach the full project including the build directories, as I zipped it after the ICE.

If possible, we would most of all appreciate a reproducer that works on the playground (this will facilitate fixing the bug faster) but if that's not possible a link to the zip would be good also.

Sorry, I didn't had enough time for it lately.
Are there any guidelines how to track down such an incremental compilation error? Unfortunately I cannot recall the steps I've done.

I've minimized the code in such a way, that removing any more causes the ICE to vanish. I'll attach this Zip-archive, so somebody else might have a look.
Note, that this is not yet a MCVE.

minimized.zip

[hellow554]

@jfrimmel any luck so far? The code looks good, now you have to recall what you did (rename a variable, changed something from a struct to a trait? Deleted members of a struct? Added functions? Removed them?)
I know it's hard to debug incremental bugs (I encountered two so far). Any chance that you can tell us, what you did between cargo clean, cargo build and the second cargo build?

[jfrimmel]

Unfortunately no. I tried to recall things, that I've done at this point, but any change I made either also ICEs or compiles fine. I've tried to reproduce this by writing the same code again, but obviously I write it a little bit different now, so I cannot get it to crash.

Are there any tips how to deal with those incremental compilation crashes? Trying to reproduce like I'm doing it now is poking around in the dark.

[hellow554]

As said, it could be anything ^^
Here are some examples I've seen so far in the wild:

#62649 (comment)
#61323 (comment)
#60629 (comment)
#58813 (comment)
#60697
#57692

[jfrimmel]

Okay, thanks, I'll have a look at the linked issues 😃

[H2CO3]

Today I encountered the same ICE with "the len is 1077 but the index is 1077".

I was writing and running some integration tests; it involved a serialization format (with Serde). I changed an [u8] array constant in a test case, then the panic occurred. When I changed it again, the ICE went away, and then I couldn't reproduce it anymore, not even with the value that seems to have caused it in the first place.

[CreepySkeleton]

We've got the same bug with the len number of 30, not on my machine but on travis-ci (the CI account isn't mine). If you guys know how to do the magic to pull the build artifacts from travis - you're welcome, CI account's owner seems willing to cooperate

[TeXitoi]

TeXitoi/structopt#229

Maybe the commit succession can be of interest to investigate the bug.

[leo60228]

I got this same panic, and it also went away after a clean build.

[AlbertoGP]

Another one here, looks like the same problem and it also went away for now after cargo clean.

Running `rustc --edition=2018 --crate-name blocks src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --emit=dep-info,link -C debuginfo=2 --test -C metadata=3630b688124f0f8c -C extra-filename=-3630b688124f0f8c --out-dir [...]/target/debug/deps -C incremental=[...]/target/debug/incremental -L dependency=[...]/target/debug/deps`
thread 'rustc' panicked at 'index out of bounds: the len is 115 but the index is 116', /builddir/rustc-1.41.1-src/src/libcore/slice/mod.rs:2806:10
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: rustc_driver::report_ice
   6: <unknown>
   7: std::panicking::rust_panic_with_hook
   8: rust_begin_unwind
   9: core::panicking::panic_fmt
  10: core::panicking::panic_bounds_check
  11: <rustc::ty::query::on_disk_cache::CacheDecoder as serialize::serialize::SpecializedDecoder<syntax_pos::span_encoding::Span>>::specialized_decode
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: rustc::ty::<impl rustc::ty::context::TyCtxt>::instance_mir
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: rustc_mir::monomorphize::collector::collect_crate_mono_items
  26: <unknown>
  27: <unknown>
  28: <unknown>
  29: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::codegen_crate
  30: <unknown>
  31: rustc_interface::queries::Queries::ongoing_codegen
  32: <unknown>
  33: <unknown>
  34: __rust_maybe_catch_panic
  35: <unknown>
  36: rust_metadata_std_3c2b88695d4d9829146c62c7533daf14
  37: <unknown>
  38: start_thread
             at /builddir/glibc-2.30/nptl/pthread_create.c:479
  39: __clone
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: internal compiler error: unexpected panic

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

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

note: rustc 1.41.1 running on powerpc64le-unknown-linux-gnu

note: compiler flags: -C debuginfo=2 -C incremental

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

query stack during panic:
#0 [optimized_mir] processing `test::find::{{closure}}#0`
#1 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack