All network requests on Windows 7 fail on 0.1.9.

[kevinpoitra]

I was using 0.1.8 up until yesterday. I ran rustup self update, it updated to 0.1.9, and now anything that makes a network request fails. Specifically, rustup throws an error here. I then tried uninstalling rustup via rustup self uninstall, and then downloaded rustup-init.exe and ran that, which also is giving the same error as it attempts to download the stable channel's current hash. Here's the error itself.

I want to say this is due to this rust-native-tls issue, but I'm not certain.

For reference, I'm on Windows 7.

[liigo]

on Windows 10, I got this error (and i think this is also a network error, based on the os error code 10054):

C:\Users\liigo>rustup update
info: syncing channel updates for 'stable-i686-pc-windows-msvc'
info: syncing channel updates for 'beta-i686-pc-windows-msvc'
 72.8 KiB /  72.8 KiB (100 %)  67.6 KiB/s ETA:   0 s
info: downloading component 'rustc'
 35.0 MiB /  35.0 MiB (100 %)   2.4 MiB/s ETA:   0 s
info: downloading component 'rust-std'
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 10054, message: "\u{8fdc}\u{7a0b}\u{4e3b}\u{673a}\u{5f3a}\u{8feb}\u{5173}\u{95ed}\u{4e86}\u{4e00}\u{4e2a}\u{73b0}\u{6709}\u{7684}\u{8fde}\u{63a5}\u{3002}" } }', ../src/libcore\result.rs:785
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread '<main>' panicked at ': "PoisonError { inner: .. }"', ../src/libcore\result.rs:785
stack backtrace:
   0:   0x59fefa - <unknown>
   1:   0x57dcd3 - <unknown>
   2:   0x57f3f0 - <unknown>
   3:   0x595892 - <unknown>
   4:   0x49aa55 - <unknown>
   5:   0x4bf50c - <unknown>
   6:   0x49e6a3 - <unknown>
   7:   0x495667 - <unknown>
   8:   0x48d35b - <unknown>
   9:   0x426a6e - <unknown>
  10:   0x41e5af - <unknown>
  11:   0x3c1df8 - <unknown>
  12:   0x3c7253 - <unknown>
  13:   0x3f101b - <unknown>
  14:   0x3f05f7 - <unknown>
  15:   0x32aa42 - <unknown>
  16:   0x3005d0 - <unknown>
  17:   0x2f3df8 - <unknown>
  18:   0x2f1048 - <unknown>
  19:   0x59f85d - <unknown>
  20:   0x59f622 - <unknown>
  21:   0x2f70be - <unknown>
  22: 0x755f38f3 - BaseThreadInitThunk
  23: 0x77af5de2 - RtlUnicodeStringToInteger
thread panicked while panicking. aborting.

[brson]

@liigo That unicode inner message says "远程主机强迫关闭了一个现有的连接。" / "It was forcibly closed by the remote host an existing connection.".

I'm guessing the PoisonError you are seeing is from the Mutex around TlsStream, but I can't imagine how.

@kevinpoitra's error looks like

error: could not download file from ...
info: caused by: failed to make network request
info: caused by: internal error
info: caused by: ProtocolError

The error information surfaced in these error messages isn't great. I want to be able to see type names for every error. And ProtocolError isn't providing a lot of information. cc @alexcrichton error reporting stuff.

@sfackler Do you understand what's happening with the errors on windows?

[sfackler]

I do not have a great understanding of the schannel stuff unfortunately.

[SpaceManiac]

Having done a marginal amount of poking, I was able to yield this (some of the debug messages mine):

InitializeSecurityContextW
DEBUG:schannel: --WRITING 189
DEBUG:schannel: Reading 7 bytes -> 7
InitializeSecurityContextW
Internal error code is -2146893018
thread '<main>' panicked at 'SEC_E_ILLEGAL_MESSAGE'

I don't actually know anything about schannel, but maybe this info can save some time?

[brson]

I've reproduced the panic @lligo sees, calling rustup update on Windows 10, under cmd.exe. I usually test under msys shell, where I don't see this.

[brson]

And I got a better stack trace

info: syncing channel updates for 'nightly-x86_64-pc-windows-gnu'
info: downloading component 'rustc'
 46.5 MiB /  46.5 MiB (100 %)   7.0 MiB/s ETA:   0 s
info: downloading component 'rust-std'
 58.6 MiB /  58.6 MiB (100 %)   5.8 MiB/s ETA:   0 s
info: downloading component 'rust-docs'
  5.7 MiB /   5.7 MiB (100 %)   2.8 MiB/s ETA:   0 s
info: downloading component 'cargo'
info: downloading component 'rust-mingw'
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 10053, message: "An established connection was aborted by the software in your host machine." } }', ../src/libcore\result.rs:785
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread '<main>' panicked at ': "PoisonError { inner: .. }"', ../src/libcore\result.rs:785
stack backtrace:
   0:   0x8d393d - std::panicking::default_hook::hc2c969e7453d080c
   1:   0x8995e1 - std::sys_common::unwind::begin_unwind_inner::h30e12d15ce2b2e25
   2:   0x595a3e - _<std..sync..PoisonError<T> as std..fmt..Debug>::fmt::h18ddd810675a2b8c
   3: 0x7703dd1f - mz_zip_writer_add_to_central_dir.constprop.15
   4: 0x7703dc2d - mz_zip_writer_add_to_central_dir.constprop.15
   5:   0x8e72aa - __rust_allocate
   6:   0x89b1e6 - std::sys_common::unwind::begin_unwind_fmt::hb2de8a9968d38523
   7:   0x8c75d2 - rust_begin_unwind
   8:   0x8e7df7 - core::panicking::panic_fmt::h257ceb0aa351d801
   9:   0x5959da - core::result::unwrap_failed::h8990054da7e28d45
  10:   0x5d6f4c - _<http..h1..Http11Message as http..message..HttpMessage>::close_connection::h27b98118b41d9ff1
  11:   0x5cb9b3 - _<client..response..Response as std..ops..Drop>::drop::h59e030c9fd2b59f5
  12: 0x7703b4a8 - mz_zip_writer_add_to_central_dir.constprop.15
  13:   0x56944c - toml..Value::drop.28786::hf039360a8930e549
  14:   0x8e7325 - __rust_deallocate
  15:   0xd2b0fb - mz_zip_writer_add_to_central_dir.constprop.15
  16:  0x1000df9 - mz_zip_writer_add_to_central_dir.constprop.15
  17: 0xffeeffed - mz_zip_writer_add_to_central_dir.constprop.15
  18:   0x49003c - _<app..settings..Flags as std..fmt..Debug>::fmt::h735c481bca563008
  19:   0x74006d - _<re_unicode..RegexSplits<'r, 't> as std..iter..Iterator>::next::h0a6075a7b1da7f82
  20:   0x720064 - regex::exec::ExecNoSync::many_matches_at::hd48dc18deeb5e09a
  21:   0x65006d - _<huffman..HuffmanDecoderError as std..fmt..Debug>::fmt::h293bdac97276814f
  22:   0x200073 - <unknown>
  23:   0x780044 - _<bcrypt..BCRYPT_DSA_PARAMETER_HEADER as std..clone..Clone>::clone::h9e05f7b10e4c8174
  24:   0x6c006f - _<[u8] as base64..ToBase64>::to_base64::h435564886020afde
  25:   0x72006e - regex::exec::ExecNoSync::many_matches_at::hd48dc18deeb5e09a
  26:   0x720064 - regex::exec::ExecNoSync::many_matches_at::hd48dc18deeb5e09a
  27:   0x45ffff - clap::args::arg::Arg::from_usage::hca286dba39a684aa
  28:   0x53004f - std..option..Option<(dist..TargetTriple, manifest..TargettedPackage)>::drop.26621::h74c99ccbdccfd1a2
  29:   0x42005e - rustup_init::multirust_mode::main::h772a5271fb006e69
  30:   0x4f0051 - _<std..iter..FilterMap<I, F> as std..iter..Iterator>::next::h5bd69d3a043b9230
  31:   0x530056 - std..option..Option<(dist..TargetTriple, manifest..TargettedPackage)>::drop.26621::h74c99ccbdccfd1a2
  32:   0x520044 - rustup_dist::dist::update_from_dist::h91f88ed9b2261682
  33:   0x55005e - rustup_dist::component::package::TarGzPackage::new::h88c73e33a8f8f0ab
  34:   0x450052 - rustup_init::proxy_mode::direct_proxy::h37bbd13facb3f408
  35:   0x5f0051 - _<header..common..cache_control..CacheDirective as std..fmt..Display>::fmt::hcf18ceb0a44e920f
  36:   0x52004f - rustup_dist::dist::update_from_dist::h91f88ed9b2261682
  37:   0x46004e - clap::args::arg::Arg::from_usage::hca286dba39a684aa
  38:   0x4c0048 - _<config..Cfg as std..fmt..Debug>::fmt::h63b5eb4279bc6b1f
  39:   0x5f0044 - _<header..common..cache_control..CacheDirective as std..fmt..Display>::fmt::hcf18ceb0a44e920f
  40:   0x540052 - rustup_dist::component::transaction::Transaction::copy_dir::h5cadeaaee502016b
  41:   0x490051 - _<app..settings..Flags as std..fmt..Debug>::fmt::h735c481bca563008
  42:   0x47004d - _<args..arg_builder..option..OptBuilder<'n, 'e> as args..any_arg..AnyArg<'n, 'e>>::validator::h98060bfd3226439a
  43:   0x44003c - regex..internal..Program::drop.62521::hcae779ca445fac52
  44:   0x660064 - toml::parser::Parser::finish_basic_string::h2b4fe1a3ecc202c8
  45:   0x750060 - regex_syntax::ByteClass::canonicalize::he72665b60aaa731c
  46:   0x74006b - _<re_unicode..RegexSplits<'r, 't> as std..iter..Iterator>::next::h0a6075a7b1da7f82
  47:   0x47ffff - clap::app::parser::Parser::validate_required::h967f409572a4abd1
  48:   0x4d004e - _<T as std..string..ToString>::to_string::h917fd1b53f1b5e46
  49:   0x440044 - regex..internal..Program::drop.62521::hcae779ca445fac52
  50:   0x490051 - _<app..settings..Flags as std..fmt..Debug>::fmt::h735c481bca563008
  51:   0x450055 - rustup_init::proxy_mode::direct_proxy::h37bbd13facb3f408
thread panicked while panicking. aborting.

[brson]

I'm running into lots of weird problems. Downloads randomly hang for a very long time.

[Diggsey]

I've also experienced long delays before the download starts, although I haven't had it fail as described here.

[pravic]

Is 0.1.8 works well? How to downgrade to it? Or it is website issue?

[brson]

@pravic 0.1.8 works but is completely insecure. There are also no release archives to download it from - the builds are gone.

[sfackler]

@brson for now it might make sense to back out of native-tls back to openssl, but include the verify stuff. I'm in the process of rewriting the schannel library and that may resolve these weird issues as well.

[brson]

That may be best, yeah.

[brson]

The stack trace in my previous message looks fairly nonsensical. Lots of interleaved frames that look unrelated.

[brson]

I've made some progress debugging the schannel integration and have identified several bugs. After fixing it seems to be performing better locally, but I won't have a patch together until tomorrow.

[brson]

I've made the fix for the long delays and eliminated the panic from mutex poisoning, but I doubt I've found the protocolerror from the OP.

Schannel is a typically complicated Win32 API and it's really hard to figure out how to use it correctly. It looks to me like schannel-rs is not doing the shutdown sequence, and I'm sure it's got more bugs.

[pravic]

0.1.8 works but is completely insecure.

Guess its better to use the unsecure version than broken one. Or at least an option to use http for non-paranoics. Offtop :(

[brson]

@pravic Yeah, plain HTTP would be a good workaround. Too bad I disabled it in the same PR that I enabled the broken TLS! I'll make another PR to enable plain HTTP.

[toothbrush7777777]

I've got the same error on Windows 7 Ultimate SP1 (Core i3 64-bit, 8 GiB RAM), using x86_64-pc-windows-gnu.

Welcome to Rust!

This will download and install the official compiler for the Rust
programming language, and its package manager, Cargo.

It will add the `cargo`, `rustc`, `rustup` and other commands to
Cargo's bin directory, located at:

C:\Users\…\.cargo\bin

This path will then be added to your `PATH` environment variable by
modifying the HKEY_CURRENT_USER/Environment/PATH registry key.

You can uninstall at any time with `rustup self uninstall` and
these changes will be reverted.

WARNING: This is beta software.

To cancel installation, type "n", or for more options type "a",
then press the Enter key to continue.

Press the Enter key to install Rust.


verbose: installing toolchain 'stable-x86_64-pc-windows-gnu'
verbose: toolchain directory: 'C:\Users\…\.multirust\toolchains\stable-x86_64-pc-windows-gnu'
info: syncing channel updates for 'stable-x86_64-pc-windows-gnu'
verbose: creating temp file: C:\Users\…\.multirust\tmp\tvtkphlg1dge2n08_file
verbose: downloading file from: 'https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256'
verbose: deleted temp file: C:\Users\…\.multirust\tmp\tvtkphlg1dge2n08_file
error: could not download file from 'https://static.rust-lang.org/dist/channel-rust-stable.toml.sha2
56' to 'C:\Users\…\.multirust\tmp\tvtkphlg1dge2n08_file
info: caused by: failed to make network request
info: caused by: internal error
info: caused by: ProtocolError
info: backtrace:

frame #0  - 0x0000000000766c63 - <no info>
frame #1  - 0x0000000000766b73 - <no info>
frame #2  - 0x0000000000590388 - <no info>
frame #3  - 0x000000000058d511 - <no info>
frame #4  - 0x000000000051c3af - <no info>
frame #5  - 0x0000000000519e5e - <no info>
frame #6  - 0x000000000051e325 - <no info>
frame #7  - 0x00000000004c8434 - <no info>
frame #8  - 0x00000000004cd3ca - <no info>
frame #9  - 0x00000000004cbd1c - <no info>
frame #10 - 0x000000000045a615 - <no info>
frame #11 - 0x0000000000424df3 - <no info>
frame #12 - 0x0000000000402c76 - <no info>
frame #13 - 0x0000000000401502 - <no info>
frame #14 - 0x000000000089c68e - <no info>
frame #15 - 0x000000000089c4bb - <no info>
frame #16 - 0x00000000004013b5 - <no info>
frame #17 - 0x00000000004014e8 - <no info>
frame #18 - 0x000000007783652d - BaseThreadInitThunk


Press the Enter key to continue.

[retep998]

For the record I just got the latest x86_64-pc-windows-msvc rustup-init on Windows 10 x64 and had no issues with it downloading and installing stuff.
rustup 0.1.9 (f3b60f5 2016-05-07)

[Arnavion]

@brson Unfortunately 0.1.10 doesn't fix the issue completely. Even though setting the two RUSTUP env vars to http:... makes rustup fetch http://static.rust-lang.org/dist/channel-rust-stable.toml, the URLs within that file are still https. So rustup still tries to download those using https and fails.

With a build where I added some logging to dump the env var in Cfg::from_env and the url in utils::download_file (lines that start with *):

* In Cfg::from_env: dist_root_url = "http://static.rust-lang.org/dist"
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
* In fn_download_file: url = "http://static.rust-lang.org/dist/channel-rust-stable.toml.sha256"
* In fn_download_file: url = "http://static.rust-lang.org/dist/channel-rust-stable.toml"
info: downloading component 'rustc'
* In fn_download_file: url = "https://static.rust-lang.org/dist/2016-04-12/rustc-1.8.0-x86_64-pc-windows-msvc.tar.gz"
error: component download failed for rustc-x86_64-pc-windows-msvc
info: caused by: could not download file from 'https://static.rust-lang.org/dist/2016-04-12/rustc-1.8.0-x86_64-pc-windows-msvc.tar.gz' to 'C:\Users\Arnavion\.multirust\tmp\9_kxryyd3e559w1u_fil
info: caused by: failed to make network request
info: caused by: internal error
info: caused by: ProtocolError

[Arnavion]

@pravic I think that error means you're still using 0.1.9.

[pravic]

Yep.

[Arnavion]

And @brson released 0.1.10 to fix that problem, which as I said in my comment doesn't fix the problem.

[brson]

@brson Unfortunately 0.1.10 doesn't fix the issue completely. Even though setting the two RUSTUP env vars to http:... makes rustup fetch http://static.rust-lang.org/dist/channel-rust-stable.toml, the URLs within that file are still https. So rustup still tries to download those using https and fails.

Indeed :(

[Arnavion]

(I worked around it by just doing set_scheme("http") in download_file. Since you're already working on the curl PR I think it's fine to wait for that.)

[pravic]

Is it fixed? 0.1.11 and today's 0.1.12 seems to work well.

[toothbrush7777777]

@pravic The current version works fine for me.

[kevinpoitra]

Tried out 0.1.12 on the machine that was originally having issues, all seems to be working fine now.