Version
Reproduced with tokio 1.12.0 and 1.13.0
Platform
Linux hostname 5.11.0-38-generic #42~20.04.1-Ubuntu SMP Tue Sep 28 20:41:07 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Description
There is a race between send(), try_recv(), and oneshot::Receiver::close(). The following program yields a panic roughly every 3 seconds on my 18c/36t workstation, compiled with Rust 1.56.1 in release mode:
#[tokio::main]
async fn main() {
loop {
let (tx, mut rx) = tokio::sync::oneshot::channel();
tokio::spawn(async move {
let _ = tx.send(());
});
tokio::spawn(async move {
rx.close();
let _ = rx.try_recv();
});
}
}All of the panics occur when send() attempts inner.consume_value().unwrap(). For example:
thread 'tokio-runtime-worker' panicked at 'called `Option::unwrap()` on a `None` value', /home/acfoltzer/.cargo/registry/src/git.832008.xyz-1ecc6299db9ec823/tokio-1.13.0/src/sync/oneshot.rs:498:50
I suspect this is a race where the rx.close(); rx.try_recv() happens between the if !inner.complete() check and the inner.consume_value().unwrap().
Version
Reproduced with tokio 1.12.0 and 1.13.0
Platform
Description
There is a race between
send(),try_recv(), andoneshot::Receiver::close(). The following program yields a panic roughly every 3 seconds on my 18c/36t workstation, compiled with Rust 1.56.1 in release mode:All of the panics occur when
send()attemptsinner.consume_value().unwrap(). For example:I suspect this is a race where the
rx.close(); rx.try_recv()happens between theif !inner.complete()check and theinner.consume_value().unwrap().