Missing calls of WSAStartup in Windows

[zonyitoo]

I have found errors in my AppVeyor build log, which is proxy with a server/client (TcpListener and TcpStream).

Error { repr: Os { code: 10093, message: "Either the application has not called WSAStartup, or WSAStartup failed." } }

I have searched in tokio-core and mio, miow's repo for WSAStartup, but I found nothing.

Maybe we have missing some necessary initializations??

[alexcrichton]

Hm so in theory everything is transitively initialized through libstd. All of tokio-core's types call into mio, and mio calls into net2-rs and net2-rs has a thunk which touches libstd types which should call WSAStartup.

Maybe the call is failing? Do you have sample code that could be used to reproduce locally?

[zonyitoo]

The problem is I don't have a Windows machine. This error keep showing up in AppVeyor's message.

• AppVeyor build: https://ci.appveyor.com/project/zonyitoo/shadowsocks-rust-ug3pm/build/job/q8jif5r50ame44er
• Related code: One of the test in here

ERROR:shadowsocks::relay::tcprelay::server: Server run failed: Either the application has not called WSAStartup, or WSAStartup failed. (os error 10093)
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 10093, message: "Either the application has not called WSAStartup, or WSAStartup failed." } }', src\libcore\result.rs:860
note: Run with `RUST_BACKTRACE=1` for a backtrace.
ERROR:shadowsocks::relay::tcprelay::socks5_local: Failed to handle client: Either the application has not called WSAStartup, or WSAStartup failed. (os error 10093)
thread '<unnamed>' panicked at 'cannot access stderr during shutdown', src\libcore\option.rs:823
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 10093, message: "Either the application has not called WSAStartup, or WSAStartup failed." } }', src\libcore\result.rs:860

This log shows that it was panicked in the server thread, which was forced close after the main test function was exited (test .. ok message has already been shown). So I suspect whether there is something wrong in the destruction order?

[alexcrichton]

Hm yeah I know I've seen weird stuff happen in the past where the main thread exits and there's threads still running in the process. If you deterministically join all spawned threads and ensure everything exits before the main thread does it make the errors go away?

[zonyitoo]

Well, currently it is impossible ... because the Poll is now blocking on run, which is TcpListener::accept.

Maybe I can add a select on it ... Hmm..

[zonyitoo]

It shouldn't be tokio's fault. So I am closing this issue now. Hope @alexcrichton could find out why this error messages keep showing up while threads are destroyed after the main function.

[alexcrichton]

I'll note though that I'm not certain that's the cause of this, I've just seen weird behavior happen around the main thread exiting before. The actual bug here may be entirely unrelated!

[zonyitoo]

Reopening .. for later discussion.