thread 'rustc' panicked at 'attempted to read from stolen value: rustc_middle::mir::Body'

[sportelliluciano]

Hello, while trying to build a project I hit an ICE. Unfortunately, I could not isolate the bug. It seems to be related to incremental builds because when I removed the target directory it started working again. I'm not providing the whole code because I couldn't reproduce the bug but I'll try to give you some context.

The project consists of three crates:

• A "traits" crate, which provides some definitions for abstractions, some of them using async-trait 0.1.52
• A "filesystem driver" crate, which contains code for parsing a raw FAT file system. This is abstracted from the underlying device through the traits defined in the first crate.
• A "main" crate which implements a virtual disk device and uses the filesystem driver to parse its contents. This crate uses tokio 1.15.0.

The 'traits' crate is mostly unchanged during development. The 'main' crate has some small changes, mostly related to updates to functions and methods signatures. The 'fs' crate changes a lot.

The project is built and run through the 'main' crate. After changing some code in the 'fs' crate and trying to run the 'main' crate the compiler had an unexpected panic. I still have the target directory saved in case something there is useful for debugging, however, I don't know how to anonymize it so I'm not publishing it here (but you can contact me and I'll see what I can do about it).

Code

This is the code referred by the error message:

#[async_trait(?Send)]
impl BlockDevice for FileDevice {   // This is src/main.rs:18
    async fn read_blocks(
        &mut self,
        start_address: Address,
        count: BlockCount,
        buffer: &mut [u8],
    ) -> Result<ByteCount, BlockDeviceError> {
        if self
            .file
            .seek(SeekFrom::Start(start_address as u64))
            .is_err()
        {
            return Err(BlockDeviceError::UnknownError);
        }
        let sector = self.file.read(&mut buffer[0..(count * 512)]);
        if let Ok(bytes_read) = sector {
            Ok(bytes_read)
        } else {
            Err(BlockDeviceError::UnknownError)
        }
    }

    /// [...] docs
    async fn write_blocks(
        &mut self,
        _start_address: Address,
        _count: BlockCount,
        _buffer: &[u8],
    ) -> Result<ByteCount, BlockDeviceError> {
        Err(BlockDeviceError::UnsupportedOperation)
    }

    /// [...] docs
    async fn block_size(&self) -> ByteCount {
        512
    }
} // This is src/main.rs:61

Meta

rustc --version --verbose:

rustc 1.57.0 (f1edd0429 2021-11-29)
binary: rustc
commit-hash: f1edd0429582dd29cccacaf50fd134b05593bd9c
commit-date: 2021-11-29
host: x86_64-unknown-linux-gnu
release: 1.57.0
LLVM version: 13.0.0

lsb_release -a && uname -r:

Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:        20.04
Codename:       focal
5.4.0-91-generic

Did not check nightly/beta because the bug disappeared after running cargo clean.

Error output

thread 'rustc' panicked at 'attempted to read from stolen value: rustc_middle::mir::Body', compiler/rustc_borrowck/src/lib.rs:133:49
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/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.57.0 (f1edd0429 2021-11-29) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin

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

query stack during panic:
#0 [mir_borrowck] borrow-checking `<impl at src/main.rs:18:1: 61:2>::read_blocks::{closure#0}`
end of query stack
error: could not compile `fat-reader`

Backtrace

stack backtrace:
   0: rust_begin_unwind
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:100:14
   2: rustc_infer::infer::InferCtxtBuilder::enter
   3: rustc_borrowck::mir_borrowck
   4: core::ops::function::FnOnce::call_once
   5: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
   6: rustc_query_system::query::plumbing::try_load_from_disk_and_cache_in_memory
   7: rustc_query_system::query::plumbing::try_execute_query
   8: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::mir_borrowck
   9: rustc_query_impl::query_callbacks::mir_borrowck::try_load_from_on_disk_cache
  10: rustc_query_system::dep_graph::graph::DepGraph<K>::exec_cache_promotions
  11: <rustc_query_impl::on_disk_cache::OnDiskCache as rustc_middle::ty::context::OnDiskCache>::drop_serialized_data
  12: rustc_session::utils::<impl rustc_session::session::Session>::time
  13: rustc_data_structures::sync::join
  14: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  15: rustc_incremental::persist::save::save_dep_graph
  16: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  17: rustc_span::with_source_map
  18: scoped_tls::ScopedKey<T>::set

[BGR360]

See also #91015

[opeolluwa]

@sportelliluciano were you able to resolve the bug. I'm having a similar one and I really don't know where to look

[cjgillot]

@opeolluwa do you have a reproducer?

[opeolluwa]

@cjgillot what's a reproducer

[cjgillot]

It's a way to reliably trigger the bug. It does not need to be small, your full project (if you can share it) is ok. For incremental bugs, we accept a git history with a "working" commit, and a commit which exhibits the bug.

[opeolluwa]

Oh! Thanks for the explanation @cjgillot. I could not reproduce the error, however clearing the target directory (with cargo clean) then restarting the application works for me and I haven't experienced a similar thing

[cjgillot]

Marking as closed by #108820. Please open a new issue if this still happens.