Reached Unreachable code in Windows Named Pipe
I am developing a cross-platform daemon to handle multiple TTYACM devices in parallel.
In particular, I am leveraging serial2_tokio for serial communication and a mixture of tokio::sync::mpsc::channel and CancellationToken (from tokio_util) for communication between threads.
While everything works on both Linux and MacOS, on Windows I enter unreachable code at line 969 of mio/src/sys/windows/named_pipe.rs.
This happens inconsistently whenever I unplug multiple devices at once (in my tests, the minimum amount that triggered the issue is 3), becoming more consistent as the amount of devices I unplug together increases. I am unsure if the crash happens due to a serial port communication issue or a inter-thread communication issue, but I think the former possibility is much more likely.
I have been trying to produce a toy example that results in the crash, but I have not been successful yet. I willl update this issue as soon as I am able to do it.
2026-07-30T10:26:58Z [ERROR] (panic) thread 'tokio-rt-worker' panicked at 'internal error: entered unreachable code': /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/mio-1.2.2/src/sys/windows/named_pipe.rs:969
0: backtrace::capture::Backtrace::create
1: backtrace::capture::Backtrace::new
2: log_panics::Config::install_panic_hook::{{closure}}
3: myApp::main::{{closure}}::{{closure}}
4: std::panicking::panic_with_hook
5: std::panicking::panic_handler::{closure#0}
6: std::sys::backtrace::__rust_end_short_backtrace::<std::panicking::panic_handler::{closure#0}, !>
7: __rustc::rust_begin_unwind
8: core::panicking::panic_fmt
9: core::panicking::panic
10: mio::sys::windows::named_pipe::write_done
11: mio::sys::windows::selector::SelectorInner::select2
12: mio::poll::Poll::poll
13: tokio::runtime::io::driver::Driver::turn
14: tokio::runtime::time::Driver::park_internal
15: tokio::runtime::scheduler::multi_thread::worker::Context::park_internal
16: tokio::runtime::scheduler::multi_thread::worker::Context::run
17: tokio::runtime::context::scoped::Scoped<T>::set
18: tokio::runtime::context::runtime::enter_runtime
19: tokio::runtime::scheduler::multi_thread::worker::run
20: tokio::runtime::task::core::Core<T,S>::poll
21: tokio::runtime::task::harness::Harness<T,S>::poll
22: tokio::runtime::blocking::pool::Inner::run
23: std::sys::backtrace::__rust_begin_short_backtrace
24: core::ops::function::FnOnce::call_once{{vtable.shim}}
25: <std::sys::thread::windows::Thread>::new::thread_start
26: <unknown>
27: <unknown>
Environment
System: Dell Inspiron 5593 (x64-based)
Processor: Inter Core i5-1035G1 GPU @ 1.00GHz, 1190 MHz, 4 Core, 8 Logical Processors
OS: Microsoft Windows 11 Pro - 10.0.26200 Build 26200
rustc: 1.97
tokio: 1.53.1
mio: 1.2.2
Reached Unreachable code in Windows Named Pipe
I am developing a cross-platform daemon to handle multiple TTYACM devices in parallel.
In particular, I am leveraging serial2_tokio for serial communication and a mixture of
tokio::sync::mpsc::channelandCancellationToken(from tokio_util) for communication between threads.While everything works on both Linux and MacOS, on Windows I enter unreachable code at line
969of mio/src/sys/windows/named_pipe.rs.This happens inconsistently whenever I unplug multiple devices at once (in my tests, the minimum amount that triggered the issue is 3), becoming more consistent as the amount of devices I unplug together increases. I am unsure if the crash happens due to a serial port communication issue or a inter-thread communication issue, but I think the former possibility is much more likely.
I have been trying to produce a toy example that results in the crash, but I have not been successful yet. I willl update this issue as soon as I am able to do it.
Environment
System: Dell Inspiron 5593 (x64-based)
Processor: Inter Core i5-1035G1 GPU @ 1.00GHz, 1190 MHz, 4 Core, 8 Logical Processors
OS: Microsoft Windows 11 Pro - 10.0.26200 Build 26200
rustc: 1.97
tokio: 1.53.1
mio: 1.2.2