mio
mio copied to clipboard
tokio-rs
Windows named pipes hits unreachable code during read operation
The error occurs at this location: https://github.com/tokio-rs/mio/blob/4a5114e518b982f49ce093be6d0d2a2ab86472d1/src/sys/windows/named_pipe.rs#L871
In io.read comes State::Err with: Err The pipe has been ended. (os error 109)
This appears on both Windows 11 and Windows 10.
It reproduced almost stably when closing the laptop lid with running service and client, apparently after switching to standby mode.
If I handle this state and simply exit the read_done method without calling unreachable (and assign the same error state to io.read again. Perhaps it's better not to do this?), everything continues to work, seemingly normal. Any comments guys?
My environment works like this:
The Windows service creates a named pipe as an administrator (both PipeMode::Bytes and PipeMode::Message modes were tested). After which the client connects to it and sends a message 2 times per second and reads the response.
Even if it's a similar bug https://github.com/tokio-rs/mio/issues/1660. In any case, it is not fixed.
I can not understand. If io.read | io.write state can be Err, why is it not checked here, but only Pending is checked, and the rest is supposedly unreachable?
Here https://github.com/akahan/mio/tree/v1.0.1-dev is the code that I used to temporarily solve this problem.
I'm getting constant crashes in my application due to this, could akahan's fix be applied as it is? I've read the code but it's quite convoluted, I don't see why the Error state should be deemed unreachable at that point.
@sergioabreu-g a pull request for this would be welcome.
I can make a PR with that change but I don't know what the consequences might be. I don't have enough knowledge of the codebase to understand why that error is there or how it should be handled.
I'm also observing this issue. The scenario is the same to what @akahan describes: A windows service with a named pipe where a client connects to, sends a some bytes and waits for some response bytes from the service before closing the pipe again. In my case I can not reliably reproduce the error it only happens occasionally.
The proposed fix from akahan here looks reasonable to me but I'm no expert in this code base.
unreachable() at least seems to be wrong based on the observations.
But how to handle the error is not fully clear to me.
What's the opinion of the maintainers of mio? I really would like this to get fixed upstream if possible, thanks.
What's the opinion of the maintainers of mio?
https://github.com/tokio-rs/mio/issues/1819#issuecomment-2393617338
But really we don't have anyone that is a Windows expert anymore, so even prs for Windows hard to review at the moment.
But really we don't have anyone that is a Windows expert anymore, so even prs for Windows hard to review at the moment.
That of course makes it harder.
I will try to build a minimal example which triggers this error and try to make pull request once I can verify the fix and better understand the code base. (May take some time)
From what I can see, this piece of code has already been added like this in https://github.com/tokio-rs/mio/pull/1351 and has even been present in https://github.com/bbqsrc/mio-named-pipes/blame/cdd2dbb0d322bfec9978ce4487c65f5b22c781e3/src/lib.rs#L631-L634 since its inception 9(!) years ago. So it looks like this bug has always been there.
I've submitted a PR here that aims to fix this issue: https://github.com/tokio-rs/mio/pull/1903
