Bug in mpsc channel
zonyitoo opened this issue · comments
Step to reproduce:
- Run the
example/ring.rs
withRUST_BACKTRACE=1 cargo run --example ring -- 10 10 4
- You would see one coroutine is panicked with message
thread 'Processor #0' panicked at 'No coroutine is running yet', src/runtime/processor.rs:189
Stack trace:
stack backtrace:
1: 0x10fc3c238 - sys::backtrace::tracing::imp::write::ha0f40157033dab87T8t
2: 0x10fc3dbd5 - panicking::default_handler::_<closure>::closure.42228
3: 0x10fc3d734 - panicking::default_handler::hfa48369cd11de99dKcy
4: 0x10fc347e4 - sys_common::unwind::begin_unwind_inner::h1122abee381015baUbt
5: 0x10fba5127 - sys_common::unwind::begin_unwind::h4158147814178406820
6: 0x10fbbea24 - runtime::processor::Processor::take_current_coroutine::h4936822716245698684
7: 0x10fbbb868 - sync::mpsc::Receiver<T>::recv::h2915722332526574509
8: 0x10fbb7402 - create_node::_<closure>::closure.7216
9: 0x10fbb6dea - coio::scheduler::Scheduler::spawn_opts::_<closure>::_<closure>::closure.7206
10: 0x10fbb6cac - coio::try::_<closure>::closure.7202
11: 0x10fbb6a67 - std::panic::recover::_<closure>::closure.7197
12: 0x10fbb6a49 - sys_common::unwind::try::try_fn::h15552624096057116699
13: 0x10fc3b7d8 - __rust_try
14: 0x10fc3957e - sys_common::unwind::try::inner_try::h7ecee3e4b8b6ef00s8s
15: 0x10fbb6a00 - sys_common::unwind::try::h17979100537356221247
16: 0x10fbb685d - panic::recover::h3181483393315964186
17: 0x10fbb67a7 - try::h9948958839926392203
18: 0x10fbb65fa - coio::scheduler::Scheduler::spawn_opts::_<closure>::closure.7147
19: 0x10fbbb265 - boxed::F.FnBox<A>::call_box::h13651452381535119350
20: 0x10fc1283b - boxed::Box<FnBox<A, Output $u3d$$u20$R$GT$$u2b$$u20$$u27$a$GT$.FnOnce$LT$A$GT$::call_once::h9628849924945103469
21: 0x10fc124fd - coroutine::coroutine_initialize::__rust_abi
22: 0x10fc1247c - coroutine::coroutine_initialize::hfedf290f1e2da700O6c
As we can see, the Receiver::recv
calls Processor::take_current_coroutine
, which will panic because of Processor::current_coro is None
.
This bug can only be reproduced with more than 1 processor.
I found the bug. This is because the function haven't got the correct Processor
instance. When the coroutine is waken up, the Processor::current()
may not be the one that yielding him out. So you have to call Processor::current()
again to get the correct Processor
instance.