Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

All network requests on Windows 7 fail on 0.1.9. #423

Closed
kevinpoitra opened this issue May 8, 2016 · 28 comments
Closed

All network requests on Windows 7 fail on 0.1.9. #423

kevinpoitra opened this issue May 8, 2016 · 28 comments

Comments

@kevinpoitra
Copy link

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
Copy link

liigo commented May 9, 2016

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
Copy link
Contributor

brson commented May 9, 2016 •
edited
Loading

@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
Copy link
Member

sfackler commented May 9, 2016

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

@sfackler sfackler closed this as completed May 9, 2016
@sfackler sfackler reopened this May 9, 2016
@SpaceManiac
Copy link
Contributor

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
Copy link
Contributor

brson commented May 9, 2016

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
Copy link
Contributor

brson commented May 9, 2016

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
Copy link
Contributor

brson commented May 9, 2016

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

@Diggsey
Copy link
Contributor

Diggsey commented May 9, 2016

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

@pravic
Copy link

pravic commented May 9, 2016

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

@brson
Copy link
Contributor

brson commented May 9, 2016

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

@sfackler
Copy link
Member

sfackler commented May 9, 2016

@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
Copy link
Contributor

brson commented May 9, 2016

That may be best, yeah.

@brson
Copy link
Contributor

brson commented May 9, 2016

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

@brson
Copy link
Contributor

brson commented May 10, 2016

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 brson mentioned this issue May 10, 2016
Merged
@brson
Copy link
Contributor

brson commented May 10, 2016

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
Copy link

pravic commented May 10, 2016 •
edited
Loading

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
Copy link
Contributor

brson commented May 10, 2016

@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
Copy link

toothbrush7777777 commented May 10, 2016 •
edited
Loading

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
Copy link
Member

retep998 commented May 10, 2016 •
edited
Loading

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
Copy link

@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
Copy link

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

@pravic
Copy link

pravic commented May 11, 2016

Yep.

@Arnavion
Copy link

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

@brson
Copy link
Contributor

brson commented May 11, 2016

@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
Copy link

(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
Copy link

pravic commented May 13, 2016

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

@toothbrush7777777
Copy link

@pravic The current version works fine for me.

@kevinpoitra
Copy link
Author

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

@brson brson closed this as completed Jun 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
10 participants
@brson @SpaceManiac @liigo @Diggsey @retep998 @pravic @Arnavion @sfackler @toothbrush7777777 @kevinpoitra