Description
Summary of the issue reported in tiberius at steffengy/tiberius#87.
Issue
When building tiberius with the latest nightlies,
an UDP send using tokio's UdpSockets mysteriously fails on windows:
MIOW CompletionPort::get_many returns an Error (only for release builds)
Io(Os { code: 10047, kind: Other, message: "An address incompatible with the requested protocol was used." })
Reproduction
Checkout tiberius (or built against the version on crates.io) with the following file.
This might only reproduce on windows (in release builds!).
I have not yet confirmed on linux, the code and deps are different though so a linux build might not trigger it - the part returning the error is miow.
main.rs
use tiberius::SqlConnection;
fn main() -> Result<(), Box<std::error::Error>> {
let future = SqlConnection::connect("server=tcp:127.0.0.1\\MSSQLSERVER;database=tibtest;integratedsecurity=sspi;trustservercertificate=true");
tokio::executor::current_thread::block_on_all(future).unwrap(); // <- panic here
println!("Done.");
Ok(())
}Bisect
Bisected to commit d3ed348
@RalfJung since he might have an idea how this changeset could affect things.
Confirmed it with
- Command
cargo-bisect-rustc --start d09466ceb1374bd0ff1c490bfd50133b8ca67558 --end 4a45578bc58ff262864f72680cc02e83f5d2f5b3 --script=test.bat -v --prompt
searched toolchains d09466ceb1374bd0ff1c490bfd50133b8ca67558 through 4a45578bc58ff262864f72680cc02e83f5d2f5b3
regression in d3ed34824c31f303b98855fee6fc9213dff1f295
- test.bat
cargo run --release main.rs
Observations
I could not produce a minimal testcase that reproduces this, since removing code or abstractions always led to removing the error no matter how unrelated it seemed. My first guess therefore was it's somehow optimization related - since the error only seems to occur in release builds - but for me that doesn't quite align with the bisected commit.