compiler panic "randomly" with incremental build #60629

xNxExOx · 2019-05-08T09:27:27Z

error: internal compiler error: src\librustc\ty\query\plumbing.rs:1195: Cannot force dep node: coherent_trait(core[b9cc]::ops[0]::drop[0]::Drop[0])

thread 'rustc' panicked at 'Box<Any>', src\librustc_errors\lib.rs:635:9
stack backtrace:
   0: std::sys_common::alloc::realloc_fallback
   1: std::panicking::take_hook
   2: std::panicking::take_hook
   3: <syntax::attr::builtin::IntType as rustc::ty::util::IntTypeExt>::disr_incr
   4: std::panicking::rust_panic_with_hook
   5: <rustc_errors::snippet::Style as core::fmt::Debug>::fmt
   6: rustc_errors::Handler::bug
   7: rustc::util::bug::bug_fmt
   8: <&rustc::mir::interpret::allocation::Allocation as rustc::ty::context::Lift>::lift_to_tcx
   9: <&rustc::mir::interpret::allocation::Allocation as rustc::ty::context::Lift>::lift_to_tcx
  10: <&rustc::mir::interpret::allocation::Allocation as rustc::ty::context::Lift>::lift_to_tcx
  11: rustc::util::bug::bug_fmt
  12: rustc::util::bug::bug_fmt
  13: rustc::ty::query::plumbing::force_from_dep_node
  14: rustc::dep_graph::graph::DepGraph::try_mark_green
  15: rustc::dep_graph::graph::DepGraph::try_mark_green
  16: rustc::dep_graph::graph::DepGraph::try_mark_green
  17: rustc::dep_graph::graph::DepGraph::try_mark_green
  18: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::try_print_query_stack
  19: rustc::traits::query::dropck_outlives::<impl rustc::infer::at::At>::dropck_outlives
  20: <rustc_typeck::impl_wf_check::ImplWfCheck as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_item
  21: <rustc_typeck::check::regionck::RegionCtxt as rustc::hir::intravisit::Visitor>::visit_expr
  22: <rustc_typeck::check::regionck::RegionCtxt as rustc::hir::intravisit::Visitor>::visit_expr
  23: <rustc_typeck::outlives::explicit::ExplicitPredicatesMap as core::fmt::Debug>::fmt
  24: <rustc_typeck::check::Diverges as core::fmt::Debug>::fmt
  25: <rustc_typeck::check::regionck::RegionCtxt as rustc::hir::intravisit::Visitor>::visit_expr
  26: <rustc_typeck::check::Diverges as core::fmt::Debug>::fmt
  27: <rustc_typeck::check::regionck::RegionCtxt as rustc::hir::intravisit::Visitor>::visit_expr
  28: <rustc_typeck::outlives::explicit::ExplicitPredicatesMap as core::fmt::Debug>::fmt
  29: rustc_typeck::check::regionck::<impl rustc_typeck::check::FnCtxt>::regionck_fn
  30: <rustc_typeck::check::Diverges as core::fmt::Debug>::fmt
  31: <rustc_typeck::check::CheckItemTypesVisitor as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_item
  32: rustc::infer::unify_key::<impl ena::unify::UnifyKey for rustc::ty::sty::FloatVid>::index
  33: rustc::dep_graph::graph::DepGraph::assert_ignored
  34: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::try_print_query_stack
  35: rustc::ty::query::plumbing::force_from_dep_node
  36: rustc::dep_graph::graph::DepGraph::try_mark_green
  37: rustc::dep_graph::graph::DepGraph::try_mark_green
  38: rustc::dep_graph::graph::DepGraph::try_mark_green
  39: rustc::dep_graph::graph::DepGraph::try_mark_green
  40: rustc::dep_graph::graph::DepGraph::try_mark_green_and_read
  41: <rustc_typeck::collect::find_existential_constraints::ConstraintLocator as rustc::hir::intravisit::Visitor>::visit_trait_item
  42: rustc_typeck::check_crate
  43: rustc_interface::passes::BoxedResolver::to_expansion_result
  44: rustc_driver::set_sigpipe_handler
  45: <env_logger::filter::inner::Filter as core::fmt::Display>::fmt
  46: <env_logger::fmt::WriteStyle as core::default::Default>::default
  47: <env_logger::filter::inner::Filter as core::fmt::Display>::fmt
  48: rustc_driver::set_sigpipe_handler
  49: rustc_interface::interface::Compiler::output_file
  50: rustc_driver::set_sigpipe_handler
  51: rustc_driver::set_sigpipe_handler
  52: <env_logger::filter::inner::Filter as core::fmt::Display>::fmt
  53: <rustc_driver::Compilation as core::fmt::Debug>::fmt
  54: rustc_driver::set_sigpipe_handler
  55: _rust_maybe_catch_panic
  56: rustc_driver::set_sigpipe_handler
  57: <std::error::<impl core::convert::From<alloc::string::String> for alloc::boxed::Box<dyn +std::error::Error+core::marker::Sync+core::marker::Send>>::from::StringError as core::fmt::Display>::fmt
  58: std::sys::windows::thread::Thread::new
  59: BaseThreadInitThunk
  60: RtlUserThreadStart
query stack during panic:
#0 [dropck_outlives] computing dropck types for `Canonical { max_universe: U0, variables: [CanonicalVarInfo { kind: Region(U0) }], value: ParamEnvAnd { param_env: ParamEnv { caller_bounds: [Binder(TraitPredicate(<T as std::marker::Send>)), Binder(TraitPredicate(<T as my::prelude::ConnectionLike>)), Binder(TraitPredicate(<T as my::connection_like::ConnectionLike>)), Binder(TraitPredicate(<P as std::marker::Send>)), Binder(TraitPredicate(<P as my::prelude::Protocol>)), Binder(TraitPredicate(<P as my::queryable::Protocol>)), Binder(TraitPredicate(<TupleType as std::marker::Send>)), Binder(TraitPredicate(<TupleType as my::prelude::FromRow>)), Binder(TraitPredicate(<P as std::marker::Sized>)), Binder(TraitPredicate(<T as std::marker::Sized>)), Binder(TraitPredicate(<TupleType as std::marker::Sized>)), Binder(OutlivesPredicate(T, ReLateBound(DebruijnIndex(1), BrAnon(0)))), Binder(OutlivesPredicate(P, ReLateBound(DebruijnIndex(1), BrAnon(0)))), Binder(OutlivesPredicate(TupleType, ReLateBound(DebruijnIndex(1), BrAnon(0))))], reveal: UserFacing, def_id: None }, value: std::result::Result<std::vec::Vec<TupleType>, my::error::Error> } }`
#1 [typeck_tables_of] processing `get_all_results`
#2 [analysis] running analysis passes on this crate
end of query stack

note: rustc 1.35.0-nightly (acd8dd6a5 2019-04-05) running on x86_64-pc-windows-msvc
note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib

It have something to do with incremental build :( query stack seems to point to random function sometimes even in file that was not edited for weeks. Issue started today. Deleting target folder help for few compilations.
I do not use latest compiler because some problems with crate upgrades and incompatibilities with async/await! so the issue is not caused by the compiler version, because I use same version for a while, but it is triggered by something in my code.

Is there anything I can look for in my code that could cause these issues?

The text was updated successfully, but these errors were encountered:

hellow554 · 2019-05-08T11:14:28Z

Remember what you've done between cleaning and ICEing. (maybe auto git commit every save or similar ^^).
In my case it was just renaming a variable from map to Map which causes an ICE.

xNxExOx · 2019-05-08T12:33:46Z

when I think backward 🤔
it first appeared when I add crate slotmap, and with that crate I was able to reproduce it even with 2 lines edit to their simplest example, so at that point I think it is caused by the crate and removed it and it was fine for a while, I chose to use CHashMap that solve some problems for me.
🤔 I can not say after which change it reappear.

xNxExOx · 2019-05-08T12:39:02Z

https://docs.rs/slotmap/0.3.0/slotmap/macro.new_key_type.html

new_key_type! {
    //struct EntityKey;

    /// Key for the Player slot map.
    pub struct PlayerKey;
}
new_key_type! {
    pub struct MyKey;
}

fn main() {
    let mut players = SlotMap::with_key();
    let mut entities: SlotMap<MyKey, (f64, f64)> = SlotMap::with_key();
    let bob: PlayerKey = players.insert("bobby");
    // Now this is a type error because entities.get expects an EntityKey:
    // entities.get(bob);
}

I want to know if I could use u32 as key because I already have unique u32 so I try to implement Key trait for struct containing only u32 get error, so I tried to replace their key and still get the error, and when I commented out //struct EntityKey; it compile, I tried few other combinations, but compiler panicked a lot, so I decided it is not the crate I want and removed it prom my project.

nikomatsakis · 2019-05-09T13:19:57Z

triage:

I'm going to mark this as P-high, but it might be more of a "medium" bug. It's a bit hard to say. I think there are few bits of info that would be useful:

First and foremost, a more concrete recipe for reproducing the problem, ideally with a standalone example
Second, some idea if this is a regression -- did the problem only start recently?

xNxExOx · 2019-05-09T13:56:54Z

For the first question:
I am on windows 10 Pro 1809, CPU 1950X, 64 GB RAM and steps to reproduce are simple for me:

start IntelliJ IDEA
new rust project
to Cargo.toml add slotmap = "0.3.0"
replace main.rs with

#[macro_use]
extern crate slotmap;

use slotmap::SlotMap;

new_key_type! {
    struct EntityKey;

    /// Key for the Player slot map.
    pub struct PlayerKey;
}

fn main() {
    let mut players = SlotMap::with_key();
    let mut entities: SlotMap<EntityKey, (f64, f64)> = SlotMap::with_key();
    let bob: PlayerKey = players.insert("bobby");
    // Now this is a type error because entities.get expects an EntityKey:
    // entities.get(bob);
}

build
add MyKey as mentioned above
build ~50% chance it fail
if the build worked just rename MyKey
build failed 5 of 6 times I get that far without deleting target folder

For the second question yes it started recently when I tried this crate, but more importantly the issue persisted after I removed it, it is just much less common than every second build.

hellow554 · 2019-05-09T15:07:34Z

Sadly I cannot reproduce it. Let me try to summarize it:

cargo new bar
add sloptmap = "0.3.0" as dependency in Cargo.toml
use

#[macro_use]
extern crate slotmap;

use slotmap::SlotMap;

new_key_type! {
    struct EntityKey;

    /// Key for the Player slot map.
    pub struct PlayerKey;
}

fn main() {
    let mut players = SlotMap::with_key();
    let mut entities: SlotMap<EntityKey, (f64, f64)> = SlotMap::with_key();
    let bob: PlayerKey = players.insert("bobby");
    // Now this is a type error because entities.get expects an EntityKey:
    // entities.get(bob);
}

cargo build
use

#[macro_use]
extern crate slotmap;

use slotmap::SlotMap;

new_key_type! {
//    struct EntityKey;

    /// Key for the Player slot map.
    pub struct PlayerKey;
}

new_key_type! {
    pub struct MyKey;
}

fn main() {
    let mut players = SlotMap::with_key();
    let mut entities: SlotMap<MyKey, (f64, f64)> = SlotMap::with_key();
    let bob: PlayerKey = players.insert("bobby");
    // Now this is a type error because entities.get expects an EntityKey:
    // entities.get(bob);
}

cargo build (hope it crashes)
if not, use

#[macro_use]
extern crate slotmap;

use slotmap::SlotMap;

new_key_type! {
//    struct EntityKey;

    /// Key for the Player slot map.
    pub struct PlayerKey;
}

new_key_type! {
    pub struct MyKeY;
}

fn main() {
    let mut players = SlotMap::with_key();
    let mut entities: SlotMap<MyKeY, (f64, f64)> = SlotMap::with_key();
    let bob: PlayerKey = players.insert("bobby");
    // Now this is a type error because entities.get expects an EntityKey:
    // entities.get(bob);
}

Am I correct? Please be as precice as possible and clarify "just rename MyKey". Do you want me to change lower/upper case? Remove one character? Add one?

Your nightly seems kind of outdated. Is it still possible for you if you use the latest nightly? (I tried both, no luck)

hellow554 · 2019-05-09T15:11:03Z

🎉 It seems that it has been fixed on latest nightly, but I'm now able to reproduce it 100% with nightly-2019-04-05 (acd8dd6).

cargo new project
add sloptmap = "0.3.0" as dependency in Cargo.toml
use

#[macro_use]
extern crate slotmap;

use slotmap::SlotMap;

new_key_type! {
//    struct EntityKey;
    pub struct PlayerKey;
}

fn main() {}

cargo build
remove // in front of struct EntityKey
cargo build
add // in front of struct EntityKey again
💥

hellow554 · 2019-05-10T07:35:30Z

I would suggest to remove the P-High and I-nomiated tag, because it is fixed on nightly. I'll add the E-needstest tag. I just have to reduce the above example without external dependencies. Lets see what I can do.

@rustbot modify labels: E-needstest

michaelwoerister · 2019-05-10T10:35:52Z

Thanks a lot for looking into this, @hellow554!
@xNxExOx, can you confirm that the crash doesn't occur anymore with the latest nightly compiler?

xNxExOx · 2019-05-10T11:44:40Z

After a lot of effort I switched toolchain to nightly-2019-05-09-x86_64-pc-windows-msvc and it seems to work here (over 20 rebuilds without error)

hellow554 · 2019-05-10T11:54:31Z

@xNxExOx please do not close this issue. I created a PR which will automatically close this when it has been merged. Please reopen it

Zoxc · 2019-05-10T12:18:18Z

This is likely caused by #59517 and fixed by #59723.

hellow554 · 2019-05-10T12:32:52Z

Can confirm that the bug has been fixed in #59723 (bisecting ftw)

@nikomatsakis

…ster add regression test for rust-lang#60629 This bug was fixed, but I don't know which one. (I think it even doesn't matter at all). Added a regression test. ``` op@OP ~/m/r/s/t/incremental> rustc --version rustc 1.35.0-nightly (acd8dd6 2019-04-05) op@OP ~/m/r/s/t/incremental> rustc -C incremental= --cfg rpass1 issue-60629.rs warning: struct is never constructed: `A` --> issue-60629.rs:3:1 | 3 | struct A; | ^^^^^^^^^ | = note: #[warn(dead_code)] on by default op@OP ~/m/r/s/t/incremental> rustc -C incremental= --cfg rpass2 issue-60629.rs error: internal compiler error: src/librustc/ty/query/plumbing.rs:1195: Cannot force dep node: coherent_trait(core[c27c]::ops[0]::drop[0]::Drop[0]) thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:635:9 note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace. error: aborting due to previous error 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.35.0-nightly (acd8dd6 2019-04-05) running on x86_64-unknown-linux-gnu note: compiler flags: -C incremental ``` with latest nightly it does not crash anymore, so nothing more to do. Fixes rust-lang#60629 (accidentally removed the remote branch on github, therefore GH closed the other PR.) r? @nikomatsakis

@ghost

Rollup of 6 pull requests Successful merges: - #60529 (RFC 2008: Uninhabitedness fixes for enum variants and tests) - #60620 (Fix a couple of FIXMEs in ext::tt::transcribe) - #60659 (Tweak `Symbol` and `InternedString`) - #60692 (Extend #60676 test for nested mut patterns.) - #60697 (add regression test for #60629) - #60701 (Update mailmap for mati865) Failed merges: r? @ghost

jonas-schievink added A-incr-comp Area: Incremental compilation 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 May 8, 2019

Centril added the I-nominated label May 8, 2019

nikomatsakis added P-high High priority and removed I-nominated labels May 9, 2019

rustbot added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label May 10, 2019

hellow554 mentioned this issue May 10, 2019

Add regression test for #60629 #60696

Closed

hellow554 added a commit to hellow554/rust that referenced this issue May 10, 2019

add regression test for rust-lang#60629

a918315

hellow554 mentioned this issue May 10, 2019

add regression test for #60629 #60697

Merged

xNxExOx closed this as completed May 10, 2019

xNxExOx reopened this May 10, 2019

Centril pushed a commit to Centril/rust that referenced this issue May 10, 2019

add regression test for rust-lang#60629

c81780b

Centril mentioned this issue May 10, 2019

Rollup of 6 pull requests #60708

Merged

bors closed this as completed in #60697 May 10, 2019

hellow554 mentioned this issue Aug 13, 2019

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

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

compiler panic "randomly" with incremental build #60629

compiler panic "randomly" with incremental build #60629

xNxExOx commented May 8, 2019

hellow554 commented May 8, 2019

xNxExOx commented May 8, 2019

xNxExOx commented May 8, 2019

nikomatsakis commented May 9, 2019

xNxExOx commented May 9, 2019

hellow554 commented May 9, 2019 •

edited

Loading

hellow554 commented May 9, 2019 •

edited

Loading

hellow554 commented May 10, 2019

michaelwoerister commented May 10, 2019

xNxExOx commented May 10, 2019

hellow554 commented May 10, 2019

Zoxc commented May 10, 2019

hellow554 commented May 10, 2019

compiler panic "randomly" with incremental build #60629

compiler panic "randomly" with incremental build #60629

Comments

xNxExOx commented May 8, 2019

hellow554 commented May 8, 2019

xNxExOx commented May 8, 2019

xNxExOx commented May 8, 2019

nikomatsakis commented May 9, 2019

xNxExOx commented May 9, 2019

hellow554 commented May 9, 2019 • edited Loading

hellow554 commented May 9, 2019 • edited Loading

hellow554 commented May 10, 2019

michaelwoerister commented May 10, 2019

xNxExOx commented May 10, 2019

hellow554 commented May 10, 2019

Zoxc commented May 10, 2019

hellow554 commented May 10, 2019

hellow554 commented May 9, 2019 •

edited

Loading

hellow554 commented May 9, 2019 •

edited

Loading