I upgrade the rust to 1.25 and compilation starts failing. I use linux musl target
I tried this code:
cargo check
I expected to see this happen: Compile successful as it is on 1.24.1
Instead, this happened:
thread 'rustc' panicked at 'index out of bounds: the len is 10 but the index is 14', /checkout/src/liballoc/vec.rs:1551:10
stack backtrace:
0: 0x7f56bab27653 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h09c1ee131a74b1c4
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: 0x7f56bab1e884 - std::sys_common::backtrace::_print::h47a337b62b6d5e9e
at libstd/sys_common/backtrace.rs:71
2: 0x7f56bab2425d - std::panicking::default_hook::{{closure}}::h945a649c9017832e
at libstd/sys_common/backtrace.rs:59
at libstd/panicking.rs:380
3: 0x7f56bab23f62 - std::panicking::default_hook::hcc534c2d30fbcda3
at libstd/panicking.rs:396
4: 0x7f56bab246d0 - std::panicking::rust_panic_with_hook::h09a7a3a353dc2f38
at libstd/panicking.rs:576
5: 0x7f56bab2458e - std::panicking::begin_panic::h8327f16bde15df70
at libstd/panicking.rs:537
6: 0x7f56bab24489 - std::panicking::begin_panic_fmt::h42ff1d37404632d6
at libstd/panicking.rs:521
7: 0x7f56bab24412 - rust_begin_unwind
at libstd/panicking.rs:497
8: 0x7f56bab89500 - core::panicking::panic_fmt::h0bd854df201d1baf
at libcore/panicking.rs:71
9: 0x7f56bab894a3 - core::panicking::panic_bounds_check::hd6045bfa984e7c3a
at libcore/panicking.rs:58
10: 0x7f56b925ba45 - rustc_metadata::cstore_impl::<impl rustc::middle::cstore::CrateStore for rustc_metadata::cstore::CStore>::def_path_hash::h826933ce08b32d99
11: 0x7f56b79805d0 - rustc::ich::impls_hir::<impl rustc_data_structures::stable_hasher::HashStable<rustc::ich::hcx::StableHashingContext<'tcx>> for rustc::hir::def::Def>::hash_stable::hf18db27c0bf2284c
12: 0x7f56b756deff - <alloc::rc::Rc<T> as rustc_data_structures::stable_hasher::HashStable<CTX>>::hash_stable::h7d0de56d862538b8
13: 0x7f56b7715fb1 - rustc::dep_graph::graph::DepGraph::with_task_impl::h517d29720454a423
14: 0x7f56b7abf129 - rustc::ty::maps::<impl rustc::ty::maps::queries::item_children<'tcx>>::force::hd20bb9cbc884e6d8
15: 0x7f56b7ac0143 - rustc::ty::maps::<impl rustc::ty::maps::queries::item_children<'tcx>>::try_get::hf4e22a81effd736f
16: 0x7f56b7b11768 - rustc::ty::maps::TyCtxtAt::item_children::h9386cf746ec5c43c
17: 0x7f56b7b0b330 - rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::item_children::hf0d1971743307e6d
18: 0x7f56b918670e - core::ops::function::FnOnce::call_once::h5a4e2f4153e6fba6
19: 0x7f56b770dc6c - rustc::dep_graph::graph::DepGraph::with_task_impl::h14e25071ee066288
20: 0x7f56b7acd3bf - rustc::ty::maps::<impl rustc::ty::maps::queries::visible_parent_map<'tcx>>::force::hb839833d3c5d7633
21: 0x7f56b7ace2f2 - rustc::ty::maps::<impl rustc::ty::maps::queries::visible_parent_map<'tcx>>::try_get::ha9a171e4eb5e2d5d
22: 0x7f56b7b11d23 - rustc::ty::maps::TyCtxtAt::visible_parent_map::h77ebeb3a7f95d0a8
23: 0x7f56b78ed5c8 - rustc::ty::item_path::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::push_item_path::ha09bb66a825a8af7
24: 0x7f56b7963fb8 - rustc::util::ppaux::PrintContext::parameterized::{{closure}}::hba0f46ea6367e8cb
25: 0x7f56b796319b - rustc::util::ppaux::PrintContext::parameterized::h0f583b0cfc39718b
26: 0x7f56b7b3322c - <rustc::ty::sty::TraitRef<'tcx> as rustc::util::ppaux::Print>::print::h9fe64e9b1af00640
27: 0x7f56b7b2f8d9 - <rustc::ty::sty::Binder<rustc::ty::sty::TraitRef<'tcx>> as rustc::util::ppaux::Print>::print::{{closure}}::hddf59dc3872d497c
28: 0x7f56b7b2fac0 - rustc::util::ppaux::<impl core::fmt::Display for rustc::ty::sty::Binder<rustc::ty::sty::TraitRef<'tcx>>>::fmt::h5ae269f0b57c949e
29: 0x7f56bab8e168 - core::fmt::write::h0e7cde1cd35d743d
at libcore/fmt/mod.rs:1084
at libcore/fmt/mod.rs:1031
30: 0x7f56b9759ee6 - <rustc_typeck::astconv::AstConv<'gcx, 'tcx> + 'o>::instantiate_poly_trait_ref_inner::h3802d23851915cce
31: 0x7f56b9803c81 - rustc_typeck::collect::compute_bounds::h1a5f44b659ada4d3
32: 0x7f56b9802779 - rustc_typeck::collect::predicates_of::h12d9cb028a537ec9
33: 0x7f56b79c567b - rustc::ty::maps::<impl rustc::ty::maps::queries::predicates_of<'tcx>>::compute_result::hee350f5813ba0a49
34: 0x7f56b772c8a9 - rustc::dep_graph::graph::DepGraph::with_task_impl::ha95e97b935a69343
35: 0x7f56b79c59e4 - rustc::ty::maps::<impl rustc::ty::maps::queries::predicates_of<'tcx>>::force::hb241b30e3664ec3a
36: 0x7f56b79c6b2b - rustc::ty::maps::<impl rustc::ty::maps::queries::predicates_of<'tcx>>::try_get::h9c9040b1ff7ce84e
37: 0x7f56b7b0bb8c - rustc::ty::maps::TyCtxtAt::predicates_of::he131f9d01f8ea2f0
38: 0x7f56b7b09da8 - rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::predicates_of::h290fb438058cab73
39: 0x7f56b97fb46e - <rustc_typeck::collect::CollectItemTypesVisitor<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_impl_item::h27b1f3b1f4b33af0
40: 0x7f56b98109e8 - rustc_typeck::check_crate::{{closure}}::{{closure}}::haf4766a57872612a
41: 0x7f56b980e3cf - rustc_typeck::check_crate::h1f60189439234404
42: 0x7f56bae62939 - rustc::ty::context::TyCtxt::create_and_enter::h452ea4e7454fa0d8
43: 0x7f56baed086b - rustc_driver::driver::compile_input::h9f2059b513d7f2fa
44: 0x7f56baeed92a - rustc_driver::run_compiler::h59e7c73de384eca5
45: 0x7f56bae197aa - std::sys_common::backtrace::__rust_begin_short_backtrace::h0da0c13475152a36
46: 0x7f56bab3d32e - __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102
47: 0x7f56bae52946 - <F as alloc::boxed::FnBox<A>>::call_box::h2973aa97647f5468
48: 0x7f56bab3458b - std::sys::unix::thread::Thread::new::thread_start::h711c51a13a158afa
at /checkout/src/liballoc/boxed.rs:798
at libstd/sys_common/thread.rs:24
at libstd/sys/unix/thread.rs:90
49: 0x7f56b5a1d7fb - start_thread
50: 0x7f56ba7ecb5e - clone
51: 0x0 - <unknown>
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
Meta
rustc --version --verbose:
rustc 1.25.0 (84203cac6 2018-03-25)
binary: rustc
commit-hash: 84203cac67e65ca8640b8392348411098c856985
commit-date: 2018-03-25
host: x86_64-unknown-linux-gnu
release: 1.25.0
LLVM version: 6.0
Backtrace:
glebpom
All 25 comments
I've experienced a similar problem when running cargo test in rust-lightning-invoice. The travis build with 1.24.1 succeeds, but with 1.25.0 it fails with the error message index out of bounds: the len is 10 but the index is 14.
I also tried it out locally with the same result. But I noticed that cargo test --release works.
sgeisler
on 31 Mar 2018
In my case, this behavior depends on target (windows, osx, linux x86_64 without cross-compilation works fine), but other targets (arm, mips, i565) are unstable, depending on debug/release profile and target architecture. Also, I observed two types of error messages: 'index out of bounds: the len is 10 but the index is 14' and 'index out of bounds: the len is 10 but the index is 10'.
I did some research based on the stacktrace, and it seems like the bug was introduced in the code that was havely refactored (some thread-safety work)
glebpom
on 31 Mar 2018
I've also been having trouble trying to compile it in Crux:
I can't compile successfully 1.24.1 or 1.25.0.
ghost
on 2 Apr 2018
According to the discussion in IRC, this is probably related to https://github.com/rust-lang/rust/pull/47181
@eddyb @mtwilliams
glebpom
on 7 Apr 2018
The bisection results are:
- nightly-2018-01-13 - ok
- nightly-2018-01-14 - panic
Regression was introduces in one of these commits: https://github.com/rust-lang/rust/compare/51b0b3734...e6072a7b3
glebpom
on 7 Apr 2018
cc @michaelwoerister https://github.com/rust-lang/rust/issues/49482#issuecomment-379479072
eddyb
on 10 Apr 2018
I have not been able to reproduce this yet. rust-lightning-invoice does not build for me.
@glebpom, do you have a small sample project that exposes the problem? Also, could you try if this issue also occurs with a recent nightly version of the compiler?
michaelwoerister
on 10 Apr 2018
@michaelwoerister I guess you took the version that did compile with 1.24.1 on travis? What error do you get when you try to compile rust-lightning-invoice?
sgeisler
on 10 Apr 2018
@michaelwoerister I was able to extact a very small code, which make rustc panicking. Please, take a look on this repo https://github.com/glebpom/rustc-panic
In my case it's failing in both docker and on my local OSX machine
glebpom
on 10 Apr 2018
@glebpom Thanks a lot! I'll take a look as soon as I get a chance.
michaelwoerister
on 11 Apr 2018
Hey, @michaelwoerister any updates here? Can I help somehow with the debugging?
glebpom
on 18 Apr 2018
Yes, I can reproduce with the latest nightly on Linux. Thanks for the test case!
michaelwoerister
on 18 Apr 2018
@michaelwoerister Can this still be reproduced?
XAMPPRocky
on 29 Jun 2018
@Aaronepower it still panics on latest nightly using https://github.com/rust-lang/rust/issues/49482#issuecomment-380203930
mati865
on 29 Jun 2018
Nominating for priority assignment.
michaelwoerister
on 2 Jul 2018
triage: P-high
pnkfelix
on 12 Jul 2018
assigning to @michaelwoerister as they were most recent compiler expert to locally reproduce, and its theorized that it may be related to PR #47181
pnkfelix
on 19 Jul 2018
visiting for triage. No progress yet. Should consider either reassigning or lowering priority if we are still stalled next week.
pnkfelix
on 2 Aug 2018
So, this still reproduces, but it is a bit of a head-scratcher for me. The compiler ICE when trying to lookup a DefPathHash for some item, but the DefId of that item is not valid. Specifically, it's one of the DefId generated here: https://github.com/rust-lang/rust/blob/78ec12df020453836c3b8990c0a8dd859b774e84/src/librustc_metadata/cstore_impl.rs#L401
In the past, most cases where this happened were related to proc-macro crates which, in general, have weird/inconsistent crate metadata. However, trying to filter out proc-macro crates during visible-parent-map generation does not seem to help. Don't know yet what's going on here.
I guess the most valid solution would be to fix crate metadata for proc-macro crates. I don't think I'll have time to look into that soon, though.
michaelwoerister
on 6 Aug 2018
Visiting for compiler meeting. @michaelwoerister has done investigation (as you can see) but we still don't really know what's going on here. :(
nikomatsakis
on 9 Aug 2018
Successfully reproduced this.
arielb1
on 24 Aug 2018
Minified:
in lib.rs:
#[macro_use]
extern crate binary_macros;
pub trait KvStorage
{
fn get(&self);
}
impl<K> KvStorage for Box<K>
where
K: KvStorage + ?Sized,
{
fn get(&self) {
(**self).get()
}
}
in binary_macros/lib.rs:
#[allow(unused_imports)]
#[macro_use]
extern crate binary_macros_impl;
pub use binary_macros_impl::*;
in binary_macros_impl/lib.rs:
extern crate proc_macro;
macro_rules! proc_macro_tokenstream {
() => {
::proc_macro::TokenStream
};
}
macro_rules! proc_macro_expr_impl {
($(
$( #[$attr:meta] )*
pub fn $func:ident($input:ident: &str) -> String $body:block
)+) => {
$(
// Parses an input that looks like:
//
// ```
// #[allow(unused)]
// enum ProcMacroHack {
// Input = (stringify!(ARGS), 0).1,
// }
// ```
$( #[$attr] )*
#[proc_macro_derive($func)]
pub fn $func(input: proc_macro_tokenstream!()) -> proc_macro_tokenstream!() {
panic!()
}
)+
};
}
proc_macro_expr_impl! {
pub fn base2_impl(input: &str) -> String {
panic!()
}
pub fn base4_impl(input: &str) -> String {
panic!()
}
pub fn base8_impl(input: &str) -> String {
panic!()
}
pub fn base16_impl(input: &str) -> String {
panic!()
}
pub fn base32hex_impl(input: &str) -> String {
panic!()
}
pub fn base32_impl(input: &str) -> String {
panic!()
}
pub fn base64_impl(input: &str) -> String {
panic!()
}
pub fn base64url_impl(input: &str) -> String {
panic!()
}
pub fn base2_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base4_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base8_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base16_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base32hex_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base32_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base64_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base64url_nopad_impl(input: &str) -> String {
panic!()
}
}
steps:
rm -fr incr *.so *.rlib; mkdir incr
$RUSTC binary_macros_impl.rs --crate-type=proc-macro -L.
$RUSTC binary_macros.rs --crate-type=rlib -L.
$RUSTC lib.rs --crate-type=rlib -L. -C incremental=$PWD/incr
The problem is that the "imaginary" DefId nodes created for the proc macro naturally don't have an entry in the def path hash table. The def path hash table needs to be "imaginary" too, rather than using the table of the "real" crate.
I'll try to do that tomorrow.
arielb1
on 24 Aug 2018
So -- there is a fix for this issue in #53711. One thing we are trying to decide is whether to backport this fix to the current beta (in which case it would appear in stable in 1.29) or to let it ride the trains (in which case the fix would appear in 1.30). We would normally backport, but the fix is mildly non-trivial and so there is perhaps some risk for follow-on bugs.
I'm curious @glebpom and others to get your take on whether to backport or not.
nikomatsakis
on 30 Aug 2018
(It would perhaps be best if you commented in #53711 directly though)
nikomatsakis
on 30 Aug 2018
Related issues
modsec
路
3Comments
zhendongsu
路
3Comments
cuviper
路
3Comments
dwrensha
路
3Comments
wthrowe
路
3Comments
Most helpful comment
Successfully reproduced this.