Skip to content

New ICE in 1.55.0-nightly 6d820866a 2021-06-29 #86743

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

Closed
Jake-Shadle opened this issue Jun 30, 2021 · 12 comments
Closed

New ICE in 1.55.0-nightly 6d820866a 2021-06-29 #86743

Jake-Shadle opened this issue Jun 30, 2021 · 12 comments
Assignees
Labels
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.

Comments

@Jake-Shadle
Copy link
Contributor

Jake-Shadle commented Jun 30, 2021

Code

Unfortunately, trying to make a minimized repro for this ICE was too difficult, as this particular struct impl is extremely entangled and in quite large, minimizing it resulted in no ICE, so I'm just reporting this immediately in the hopes that it will ring a bell as this is a change that occurred between

nightly-x86_64-unknown-linux-gnu - rustc 1.55.0-nightly (a435b49e8 2021-06-28) (good)

and

nightly-x86_64-unknown-linux-gnu - rustc 1.55.0-nightly (6d820866a 2021-06-29) (ice)

type FutureHandle = u64;
pub type TrainingHandle = u64;
pub type InferenceHandle = u64;
use std::future::Future;

struct ExperimentConfigFuture;

struct MLApiHost;

struct Experiment;

impl MLApiHost {
    pub fn new() -> Self {
        loop {}
    }

    #[cfg(target_os = "linux")]
    fn refresh_system_data(&mut self) {
        loop {}
    }

    #[allow(clippy::indexing_slicing)]
    fn set_worker_module_link(&mut self, link: &str) -> anyhow::Result<()> {
        loop {}
    }

    fn list_experiments(
        &mut self,
        hive_url: String,
        hive_port: u32,
    ) -> impl Future<Output = anyhow::Result<Vec<Experiment>>> {
        std::future::ready(Err(anyhow::anyhow!("...")))
    }

    fn can_connect_to_hive(
        &self,
        hive_url: String,
        hive_port: u32,
    ) -> impl Future<Output = Result<bool, ()>> {
        std::future::ready(Err(()))
    }

    fn get_hive_connection(&mut self, handle: TrainingHandle) -> Result<(), ()> {
        loop {}
    }

    fn get_tract_connection(&mut self, handle: InferenceHandle) -> Result<(), ()> {
        loop {}
    }

    fn connect_to_experiment(
        &mut self,
        hive_url: &str,
        hive_port: u32,
        experiment_id: &str,
    ) -> impl Future<Output = anyhow::Result<TrainingHandle>> {
        std::future::ready(Err(anyhow::anyhow!("...")))
    }

    #[allow(clippy::too_many_arguments)]
    fn start_hive_training(
        &mut self,
        hive_url: &str,
        hive_port: u32,
        game_name: &str,
        experiment_name: &str,
        num_features: u32,
        num_actions: u32,
        num_remote_ark_workers: u32,
        module_config: &str,
        checkpoint: Option<&str>,
        training_duration_in_seconds: u64,
    ) -> impl Future<Output = anyhow::Result<TrainingHandle>> {
        std::future::ready(Err(anyhow::anyhow!("...")))
    }

    fn stop_experiment(
        &mut self,
        handle: TrainingHandle,
        stop_remote_workers: bool,
    ) -> impl Future<Output = Result<(), ()>> {
        std::future::ready(Err(()))
    }

    fn stop_hive_training(
        &mut self,
        handle: TrainingHandle,
    ) -> impl Future<Output = Result<(), ()>> {
        std::future::ready(Err(()))
    }

    fn start_tract_inference(
        &mut self,
        num_features: u32,
        num_actions: u32,
        snapshot_data: &[u8],
    ) -> Result<InferenceHandle, ()> {
        loop {}
    }

    fn stop_tract_inference(&mut self, handle: InferenceHandle) -> Result<(), ()> {
        loop {}
    }

    fn safe_user_name(&self) -> String {
        loop {}
    }

    fn experiment_config_from_registry(
        &mut self,
        hive_url: String,
        hive_port: u32,
        experiment_id: String,
    ) -> impl Future<Output = anyhow::Result<()>> {
        std::future::ready(Err(anyhow::anyhow!("...")))
    }

    fn download_snapshot_from_registry(
        &mut self,
        hive_url: String,
        hive_port: u32,
        experiment_id: String,
    ) -> impl Future<Output = Result<Vec<u8>, ()>> {
        std::future::ready(Err(()))
    }

    fn experiment_config_to_ffi(
        &mut self,
        config: impl Future<Output = anyhow::Result<()>> + Send + 'static,
    ) -> ExperimentConfigFuture {
        loop {}
    }
}

Meta

rustc --version --verbose:

rustc 1.55.0-nightly (6d820866a 2021-06-29)
binary: rustc
commit-hash: 6d820866a27b1949e237be79b9c8c0145fe728b7
commit-date: 2021-06-29
host: x86_64-unknown-linux-gnu
release: 1.55.0-nightly
LLVM version: 12.0.1

Error output

thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 163', /cargo/registry/src/github.com-1ecc6299db9ec823/ena-0.14.0/src/snapshot_vec.rs:199:10
Backtrace

stack backtrace:
   0: rust_begin_unwind
             at /rustc/6d820866a27b1949e237be79b9c8c0145fe728b7/library/std/src/panicking.rs:515:5
   1: core::panicking::panic_fmt
             at /rustc/6d820866a27b1949e237be79b9c8c0145fe728b7/library/core/src/panicking.rs:92:14
   2: core::panicking::panic_bounds_check
             at /rustc/6d820866a27b1949e237be79b9c8c0145fe728b7/library/core/src/panicking.rs:69:5
   3: rustc_infer::infer::InferCtxt::shallow_resolve_ty
   4: <smallvec::SmallVec<A> as core::iter::traits::collect::Extend<<A as smallvec::Array>::Item>>::extend
   5: rustc_middle::ty::fold::TypeFoldable::fold_with
   6: rustc_middle::ty::structural_impls::<impl rustc_middle::ty::fold::TypeFoldable for &rustc_middle::ty::TyS>::super_fold_with
   7: rustc_middle::ty::fold::TypeFoldable::fold_with
   8: rustc_middle::ty::structural_impls::<impl rustc_middle::ty::fold::TypeFoldable for &rustc_middle::ty::TyS>::super_fold_with
   9: rustc_infer::infer::InferCtxtBuilder::enter
  10: core::ops::function::FnOnce::call_once
  11: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  12: rustc_data_structures::stack::ensure_sufficient_stack
  13: rustc_query_system::query::plumbing::get_query_impl
  14: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::normalize_generic_arg_after_erasing_regions
  15: <rustc_middle::ty::normalize_erasing_regions::NormalizeAfterErasingRegionsFolder as rustc_middle::ty::fold::TypeFolder>::fold_ty
  16: rustc_middle::ty::normalize_erasing_regions::<impl rustc_middle::ty::context::TyCtxt>::normalize_erasing_regions
  17: rustc_middle::ty::util::<impl rustc_middle::ty::TyS>::has_significant_drop
  18: rustc_typeck::check::upvar::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::analyze_closure
  19: rustc_hir::intravisit::walk_expr
  20: rustc_hir::intravisit::walk_expr
  21: <rustc_typeck::check::upvar::InferBorrowKindVisitor as rustc_hir::intravisit::Visitor>::visit_expr
  22: rustc_hir::intravisit::walk_expr
  23: <rustc_typeck::check::upvar::InferBorrowKindVisitor as rustc_hir::intravisit::Visitor>::visit_expr
  24: rustc_typeck::check::upvar::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::closure_analyze
  25: rustc_infer::infer::InferCtxtBuilder::enter
  26: rustc_typeck::check::typeck
  27: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  28: rustc_data_structures::stack::ensure_sufficient_stack
  29: rustc_query_system::query::plumbing::force_query_with_job
  30: rustc_query_system::query::plumbing::get_query_impl
  31: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck
  32: rustc_middle::ty::<impl rustc_middle::ty::context::TyCtxt>::par_body_owners
  33: rustc_typeck::check::typeck_item_bodies
  34: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  35: rustc_data_structures::stack::ensure_sufficient_stack
  36: rustc_query_system::query::plumbing::force_query_with_job
  37: rustc_query_system::query::plumbing::get_query_impl
  38: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck_item_bodies
  39: rustc_session::utils::<impl rustc_session::session::Session>::time
  40: rustc_typeck::check_crate
  41: rustc_interface::passes::analysis
  42: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  43: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  44: rustc_query_system::dep_graph::graph::DepGraph<K>::with_eval_always_task
  45: rustc_data_structures::stack::ensure_sufficient_stack
  46: rustc_query_system::query::plumbing::force_query_with_job
  47: rustc_query_system::query::plumbing::get_query_impl
  48: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
  49: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  50: rustc_span::with_source_map
  51: rustc_interface::interface::create_compiler_and_run
  52: scoped_tls::ScopedKey<T>::set
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://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.55.0-nightly (6d820866a 2021-06-29) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental -C link-arg=-fuse-ld=lld -C link-arg=-Wl,--build-id=sha1

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

query stack during panic:
#0 [normalize_generic_arg_after_erasing_regions] normalizing `impl std::future::Future`
#1 [typeck] type-checking `host_api::ml::<impl at components/module-host/src/host_api/ml.rs:264:1: 920:2>::experiment_config_to_ffi`
#2 [typeck_item_bodies] type-checking all item bodies
#3 [analysis] running analysis passes on this crate
end of query stack

@Jake-Shadle Jake-Shadle added 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 Jun 30, 2021
@Jake-Shadle
Copy link
Contributor Author

To add a little more info, the #1 line in the query stack

#1 [typeck] type-checking host_api::ml::<impl at components/module-host/src/host_api/ml.rs:264:1: 920:2>::experiment_config_to_ffi

is calling out the entire impl body of the MLHost struct, and the experiment_config_to_ffi method is the last method in that impl, if that helps investigation in any way.

@fee1-dead
Copy link
Member

Please don't provide a block of code that does not reproduce the issue. At least attach a link to a repository of some kind.

@Jake-Shadle
Copy link
Contributor Author

The repository is currently private, otherwise I would have.

@Jake-Shadle
Copy link
Contributor Author

I forgot https://github.com/rust-lang/cargo-bisect-rustc existed, running that now to pin down the exact commit that introduced this ICE.

@Jake-Shadle
Copy link
Contributor Author

I've bisected the change to be in 1ea0e28, will attempt to narrow it down further.

@arora-aman
Copy link
Member

I think this coming from the precise capture lint. I saw something similar when trying to run the lint on the compiler last night.

There is an additional check in the Drop part of the migration that checks for bugs in the existing code that seems to be causing the issue.

Removing it seems to fix the issue when the lint is run on the compiler, I'll discuss this during WG sync today if we should remove the check or figure out a way for it to not fail.

@lqd
Copy link
Member

lqd commented Jun 30, 2021

Does the precise capture lint/migration check run on code that doesn't enable the capture_disjoint_fields gate nor the 2021 edition ?

@arora-aman
Copy link
Member

The lint has been added part of the edition lint, I'm not sure if it gets run on its own. But the backtrace confirms it goes through the lint part of code.

@nikomatsakis
Copy link
Contributor

@rustbot assign @arora-aman

Is this the ICE we were talking about yesterday, where we had to remove the check that was meant to catch 'code that wouldn't have compiled anyway?')

@arora-aman
Copy link
Member

Yes @nikomatsakis. I'll have PR up today

@nikomatsakis
Copy link
Contributor

Potentially related to #84841

@nikomatsakis
Copy link
Contributor

No longer reproduces. I'm going to assume this was a duplicate. Closing as we already have the relevant tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.
Projects
None yet
Development

No branches or pull requests

5 participants