panicked on RecvError in src/diskio/mod.rs

[alecmocatta]

Problem

With this rust-toolchain.toml:

[toolchain]
channel = "nightly-2021-12-08"
components = ["rustfmt", "clippy", "rust-src"]
targets = ["wasm32-unknown-unknown"]
profile = "minimal"

I got this panic:

% cargo run
info: syncing channel updates for 'nightly-2021-12-08-aarch64-apple-darwin'
info: latest update on 2021-12-08, rust version 1.59.0-nightly (0b6f079e4 2021-12-07)
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'rust-src'
info: downloading component 'rust-std'
info: downloading component 'rust-std' for 'wasm32-unknown-unknown'
info: downloading component 'rustc'
info: downloading component 'rustfmt'
info: installing component 'cargo'
info: installing component 'clippy'
info: installing component 'rust-src'
info: installing component 'rust-std'
info: installing component 'rust-std' for 'wasm32-unknown-unknown'
info: installing component 'rustc'
thread 'CloseHandle' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', src/diskio/mod.rs:421:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Unfortunately it doesn't reproduce; the next run was successful:

% RUST_BACKTRACE=1 cargo run
info: syncing channel updates for 'nightly-2021-12-08-aarch64-apple-darwin'
info: latest update on 2021-12-08, rust version 1.59.0-nightly (0b6f079e4 2021-12-07)
info: downloading component 'clippy'
info: downloading component 'rust-src'
info: downloading component 'rust-std' for 'wasm32-unknown-unknown'
info: downloading component 'rustfmt'
info: downloading component 'rustc'
warning: bad checksum for cached download
info: downloading component 'cargo'
info: downloading component 'rust-std'
info: removing previous version of component 'rustc'
warning: during uninstall component rustc was not found
info: removing previous version of component 'cargo'
warning: during uninstall component cargo was not found
info: removing previous version of component 'rust-std'
warning: during uninstall component rust-std was not found
info: removing previous version of component 'rustfmt'
warning: during uninstall component rustfmt was not found
info: removing previous version of component 'clippy'
warning: during uninstall component clippy was not found
info: installing component 'clippy'
info: installing component 'rust-src'
info: installing component 'rust-std' for 'wasm32-unknown-unknown'
info: installing component 'rustfmt'
info: installing component 'rustc'
info: installing component 'cargo'
info: installing component 'rust-std'

Steps

I haven't been able to repro, and I don't know if it's specific to rust-toolchain.toml with cargo run, but this is the scenario I observed it in:

1. Have a rust-toolchain.toml with a different toolchain version in
2. cargo run, triggering a toolchain install

Possible Solution(s)

No response

Notes

No response

Rustup version

rustup 1.24.3 (ce5817a94 2021-05-31)

Installed toolchains

Default host: aarch64-apple-darwin
rustup home:  /Users/alecmocatta/.rustup


installed toolchains
--------------------

stable-aarch64-apple-darwin
nightly-2021-11-07-aarch64-apple-darwin
nightly-2021-11-13-aarch64-apple-darwin
nightly-2021-12-08-aarch64-apple-darwin
nightly-aarch64-apple-darwin (default)

installed targets for active toolchain
--------------------------------------

aarch64-apple-darwin
wasm32-unknown-unknown

active toolchain
----------------

nightly-2021-12-08-aarch64-apple-darwin (overridden by '/Users/alecmocatta/Downloads/tably/rust-toolchain.toml')
rustc 1.59.0-nightly (0b6f079e4 2021-12-07)

[kinnison]

Without a semi-reliable way to trigger this, there's not a lot we can do to diagnose.

The unwrap() in question occurs normally in another thread and so should not cause the main process to fail. The only way that unwrap could have failed would be if the main thread had encountered an issue which should have been reported also.

I suppose we could transform the Option<FileBuffer> into a io::Result<FileBuffer> and then return with an ErrorKind::Other so that the panic at least does not happen.

@rbtcollins How do you feel about that small refactor at least?

[rbtcollins]

I'm not sure that will fix the panic. Isn't this the code in question? https://github.com/rust-lang/rustup/blob/master/src/diskio/mod.rs#L413-L415

[kinnison]

@rbtcollins Yes, that's exactly the location, I just wonder if a non-primary thread panicing has caused the real error to get lost, perhaps being more graceful here might result in a better error to the user from the main thread?