[Stable] ICE on Windows 7 when compiling dependencies

18ab087
Opened by jjpe at 2023-07-22 18:09:06

UPDATE 2: I just talked over this issue on internals and it strongly looks like this ICE is triggered because the code was effectively on a network drive. I moved the project to an internal disk, and now it compiles fine. Still, I'd rather not close this issue just yet, as it would be nice to be able to compile from a network drive without ICE. This bug also seems related to this one, and is perhaps even a duplicate.

UPDATE: I just tried this with stable rustc 1.20.0 (f3d6973f4 2017-08-27) running on i686-pc-windows-msvc, and get the same result as with nightly.

I'm trying to compile a project for work on Windows 7 using rustc 1.22.0-nightly (c6884b12d 2017-09-30), but compilation fails when trying to build the project's dependencies. Interesting to note is that the same rustc version on OS X has no issues with the same project.

The log output follows:

F:\quip (master)
λ cargo run --bin sxi
warning: could not canonicalize path: 'F:\quip'
warning: could not canonicalize path: 'F:\quip'
warning: could not canonicalize path: 'F:\'
   Compiling kernel32-sys v0.2.2
error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.22.0-nightly (c6884b12d 2017-09-30) running on i686-pc-windows-msvc

note: run with `RUST_BACKTRACE=1` for a backtrace

thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 1, message: "Incorrect function." } }', src\libcore\result.rs:906:4
stack backtrace:
   0: 0x62d9131d - std::panicking::Location::column::h9895b0760262a28a
   1: 0x62d90fba - std::panicking::Location::column::h9895b0760262a28a
   2: 0x62d91868 - std::panicking::rust_panic_with_hook::h8f20d66610e2b881
   3: 0x62d916de - std::panicking::begin_panic_fmt::hb90e383f78c9754f
   4: 0x62d91667 - std::panicking::begin_panic_fmt::hb90e383f78c9754f
   5: 0x62d915b9 - rust_begin_unwind
   6: 0x62da430a - core::panicking::panic_fmt::hf1b6bd69ee550bb9
   7: 0x5c586a14 - rustc_metadata::cstore::CrateMetadata::needs_panic_runtime::h066b1941f56c69e2
   8: 0x5c66682b - rustc_metadata::locator::Context::report_errs::he94b06f72750cbc6
   9: 0x5c65b93f - rustc_metadata::creader::CrateLoader::new::h948973d8362524be
  10: 0x5c657bef - rustc_metadata::creader::CrateLoader::new::h948973d8362524be
  11: 0x5c660ca2 - <rustc_metadata::creader::CrateLoader<'a> as rustc::middle::cstore::CrateLoader>::process_item::h8732ec1d24fcb8e2
  12: 0x5cb69b45 - rustc_resolve::build_reduced_graph::<impl rustc_resolve::ToNameBinding<'a> for (rustc::hir::def::Def, rustc::ty::Visibility, syntax_pos::span_encoding::Span, syntax_pos::hygiene::Mark)>::to_name_binding::hdcec3f8b36125949
  13: 0x5cb70fa6 - <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as syntax::visit::Visitor<'a>>::visit_item::hf1aa69c66ee40100
  14: 0x5cb711cc - <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as syntax::visit::Visitor<'a>>::visit_item::hf1aa69c66ee40100
  15: 0x5cb61b8a - rustc_resolve::macros::<impl syntax::ext::base::Resolver for rustc_resolve::Resolver<'a>>::visit_expansion::h1eebd66536c4d25a
  16: 0x62a49a30 - syntax::ext::expand::MacroExpander::expand_crate::h7773bd6ef2621edf
  17: 0x62a3f949 - syntax::ext::expand::MacroExpander::expand_crate::h7773bd6ef2621edf
  18: 0x62a3f3c7 - syntax::ext::expand::MacroExpander::expand_crate::h7773bd6ef2621edf
  19: 0x63d4b353 - rustc_driver::driver::count_nodes::h39504b0a4a68bcf8
  20: 0x63d468ef - rustc_driver::driver::count_nodes::h39504b0a4a68bcf8
  21: 0x63d3e246 - rustc_driver::driver::compile_input::h9417596b5d9e2ea9
  22: 0x63d5e975 - rustc_driver::run_compiler::hf870ea00b3ee6606
  23: 0x63c756cb - <unknown>
  24: 0x62d9899b - _rust_maybe_catch_panic
  25: 0x63cae93f - <rustc_driver::derive_registrar::Finder as rustc::hir::itemlikevisit::ItemLikeVisitor<'v>>::visit_impl_item::h8a468c2ea6f8f76e
  26: 0x62d8f67c - std::sys::imp::thread::Thread::new::h08d4b413205a3a97
  27: 0x76923c44 - BaseThreadInitThunk
  28: 0x76e037f4 - RtlInitializeExceptionChain

error: Could not compile `kernel32-sys`.

To learn more, run the command again with --verbose.

  1. The canonicalize code is similar to libuv but a couple flags are different - I suspect the problem has to do with those flags, but I'll need to set up a network drive to test it.

    Parker Snell at 2017-10-08 18:50:01

  2. I've been unable to repro this on Windows 10 - wrote a test program that canonicalizes a network path and tried running it through a symlink, hard link, .bat script, and various different startup args. All work for me. I can also build a project on a network drive with my local cargo, so whatever is causing this must have been fixed in Win10.

    The one exception is if I open an admin shell, I lose the network drive. I also can't create a project on the remote drive - it's mapped onto my Mac, and it seems you can't create dot files with the flags Cargo is using (fails at trying to create .gitignore). But if I create the project with the macOS Cargo, I can build it with Windows cargo.

    I know a bunch of system path handling functions were changed in Win10 to allow long paths. Canonicalize calls CreateFile and GetFinalPathNameByHandle and neither of those should have issues with network paths. Unfortunately I'm kind of stuck if I can't repro this. I'd try setting a breakpoint in the canonicalize function (libstd/sys/windows/fs.rs) and check the return values, paths going in and out, and GetLastError() for both of those functions I mentioned.

    Parker Snell at 2017-10-13 18:44:59

  3. The same has happened to me. I am using an official MS VirtualBox trial image downloaded from here, combination IE11 on Win7 (x86)/VirtualBox. When building a project on a VirtualBox shared folder, I get this:

    D:\projects\kzvcore>cargo test --jobs 1 --all
    warning: could not canonicalize path: 'D:\projects\kzvcore'
    warning: could not canonicalize path: 'D:\projects\kzvcore'
    warning: could not canonicalize path: 'D:\projects'
    warning: could not canonicalize path: 'D:\'
       Compiling owning_ref v0.3.3
    error: internal compiler error: unexpected panic
    
    note: the compiler unexpectedly panicked. this is a bug.
    
    note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/m
    aster/CONTRIBUTING.md#bug-reports
    
    note: rustc 1.23.0 (766bd11c8 2018-01-01) running on i686-pc-windows-msvc
    
    note: run with `RUST_BACKTRACE=1` for a backtrace
    
    thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Error {
     repr: Os { code: 1, message: "Incorrect function." } }', src\libcore\result.rs:
    906:4
    stack backtrace:
       0: std::panicking::Location::column
       1: std::panicking::Location::column
       2: std::panicking::rust_panic_with_hook
       3: std::panicking::begin_panic_fmt
       4: std::panicking::begin_panic_fmt
       5: rust_begin_unwind
       6: core::panicking::panic_fmt
       7: <rustc_metadata::creader::ExternCrateInfo as core::fmt::Debug>::fmt
       8: rustc_metadata::locator::Context::maybe_load_library_crate
       9: rustc_metadata::creader::CrateLoader::new
      10: rustc_metadata::creader::CrateLoader::new
      11: <rustc_metadata::creader::CrateLoader<'a> as rustc::middle::cstore::CrateL
    oader>::process_item
      12: rustc_resolve::build_reduced_graph::<impl rustc_resolve::ToNameBinding<'a>
     for (&'a rustc_resolve::ModuleData<'a>, rustc::ty::Visibility, syntax_pos::span
    _encoding::Span, syntax_pos::hygiene::Mark)>::to_name_binding
      13: <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as s
    yntax::visit::Visitor<'a>>::visit_item
      14: <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as s
    yntax::visit::Visitor<'a>>::visit_ty
      15: <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as s
    yntax::visit::Visitor<'a>>::visit_item
      16: <rustc_resolve::resolve_imports::SingleImports<'a> as core::default::Defau
    lt>::default
      17: syntax::ext::expand::MacroExpander::expand_crate
      18: syntax::ext::expand::MacroExpander::expand_crate
      19: syntax::ext::expand::MacroExpander::expand_crate
      20: <rustc_driver::Compilation as core::fmt::Debug>::fmt
      21: <rustc_driver::Compilation as core::fmt::Debug>::fmt
      22: rustc_driver::driver::compile_input
      23: rustc_driver::run_compiler
      24: <rustc_driver::pretty::UserIdentifiedItem as core::fmt::Debug>::fmt
      25: _rust_maybe_catch_panic
      26: <rustc_driver::derive_registrar::Finder as rustc::hir::itemlikevisit::Item
    LikeVisitor<'v>>::visit_trait_item
      27: std::sys::imp::thread::Thread::new
      28: BaseThreadInitThunk
      29: RtlInitializeExceptionChain
    
    error: Could not compile `owning_ref`.
    
    To learn more, run the command again with --verbose.
    

    When I copy the project to a local path, it compiles. The project has multiple dependencies, and it seems that the error: Could not compile owning_ref. line changes non-deterministically upon repeated runs.

    Tomas Dvorak at 2018-01-06 17:43:55