mio: tcp_stream test fails with TcpStream::set_ttl crash

Problem: When running the unit tests on Windows 8.1 Pro, tcp_stream ttl test crash in TcpStrea::set_ttl :

RUST_BACKTRACE=1 cargo test --test tcp_stream
    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
     Running target\debug\deps\tcp_stream-7340f8b6dbab4dde.exe

running 12 tests
test is_send_and_sync ... ok
test shutdown_write ... ignored
test tcp_stream_ipv4 ... ignored
test tcp_stream_ipv6 ... ignored
test ttl ... FAILED
test registering ... ok
test deregistering ... ok
test nodelay ... ok
test reregistering ... ok
test shutdown_both ... ok
test shutdown_read ... ok
test try_clone ... ok

failures:

---- ttl stdout ----
thread 'ttl' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 10022, kind: InvalidInput, message: "An invalid argument was supplied." }', src\libcore\result.rs:1084:5
stack backtrace:
   0: backtrace::backtrace::trace_unsynchronized
             at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.34\src\backtrace\mod.rs:66
   1: std::sys_common::backtrace::_print
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\sys_common\backtrace.rs:47
   2: std::sys_common::backtrace::print
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\sys_common\backtrace.rs:36
   3: std::panicking::default_hook::{{closure}}
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\panicking.rs:200
   4: std::panicking::default_hook
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\panicking.rs:211
   5: std::panicking::rust_panic_with_hook
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\panicking.rs:477
   6: std::panicking::continue_panic_fmt
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\panicking.rs:384
   7: std::panicking::rust_begin_panic
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libstd\panicking.rs:311
   8: core::panicking::panic_fmt
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libcore\panicking.rs:85
   9: core::result::unwrap_failed
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libcore\result.rs:1084
  10: core::result::Result<(), std::io::error::Error>::unwrap<(),std::io::error::Error>
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\libcore\result.rs:852
  11: tcp_stream::ttl
             at .\tests\tcp_stream.rs:177
  12: tcp_stream::ttl::{{closure}}
             at .\tests\tcp_stream.rs:168
  13: core::ops::function::FnOnce::call_once<closure-0,()>
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\libcore\ops\function.rs:235
  14: alloc::boxed::{{impl}}::call_once<(),FnOnce<()>>
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\liballoc\boxed.rs:787
  15: panic_unwind::__rust_maybe_catch_panic
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libpanic_unwind\lib.rs:80
  16: std::panicking::try
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\libstd\panicking.rs:275
  17: std::panic::catch_unwind
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\src\libstd\panic.rs:394
  18: test::run_test::run_test_inner::{{closure}}
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54\/src\libtest\lib.rs:1408
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


failures:
    ttl

test result: FAILED. 8 passed; 1 failed; 3 ignored; 0 measured; 0 filtered out

Cause: According to @PerfectLaugh:

I figured it out that the windows tcpstream::connect was not allowed to use set_ttl when you aren't not connected yet since we used the non_blocking on connect

Solution: ?

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 26 (16 by maintainers)

Commits related to this issue

Fix for issue #1117, temporary fix for set_ttl test on Windows, this test was crashing on Windows because, on Windows calling setsockopt on a not connected socket is undefined behavior. More details c... — committed to dtacalau/mio by dtacalau 5 years ago

Most upvoted comments

@Thomasdezeeuw yes, this is wip. Me and Mark have continued investigating this. Biggest problem here is that the issue repro on my machine only. Mark was unable to repro this on his machines.

Mark has prepared a set of custom drivers with more debug info which I installed on a machine where the issue repro. But unfortunately issue did not reproduce under custom drivers. Anything that slows down the machine renders the issue to not reproduce anymore.

Next, Mark has prepared a minimalist repro test that just keep running until it hits the issue, so he’s trying to isolate the issue from mio and rust and repro-ing it in another context. The most important part here is to find a way to reproduce it on other machines too.

dtacalau on Dec 4, 2019

@Thomasdezeeuw to wrap up our discussion: I’ve commited a fix for the set_ttl test, but not really satisfied with the fix (since this is only a Windows limitation, other platforms would not need the extra register and wait).

This this is more or less the best we can do without introducing overhead elsewhere, if you’re talking about registering before calling set_ttl as done in #1120. Personally I’m OK with that since most, if not all, use cases involve registering the stream at some point.

Would like to know your thoughts on my ideas above: benchmarks, adding a new CONFIGURABLE interest. Thanks!

I not really in favour of a configurable interest because I wouldn’t know that would be? I think it would just be another name for writable on Windows? But then you have an awkward situation in which you’ll get an writable event even though you only registered configurable interests.

As for the benchmarks; there very welcome. I think the API is starting to stabilise so we I think the work to maintain them won’t be too much.

Thomasdezeeuw on Nov 4, 2019