ICE on Windows GNU ABI Nightly 1.8 (2016-01-23)

[canndrew]

I'm trying to test this PR on windows (specifically this commit) but the compiler is bugging out.

The full output is:

$ cargo build --verbose
       Fresh ip v1.1.0
       Fresh libc v0.1.12
       Fresh c_linked_list v0.1.0
   Compiling get_if_addrs v0.3.0 (file:///E:/maidsafe/get_if_addrs)
     Running `rustc src\lib.rs --crate-name get_if_addrs --crate-type lib -g --out-dir E:\maidsafe\get_if_addrs\target\debug --emit=dep-info,link -L dependency=E:\maidsafe\get_if_addrs\target\debug -L dependency=E:\maidsafe\get_if_addrs\target\debug\deps --extern c_linked_list=E:\maidsafe\get_if_addrs\target\debug\deps\libc_linked_list-e29420960369b25b.rlib --extern libc=E:\maidsafe\get_if_addrs\target\debug\deps\liblibc-6f18902dd8f75ffb.rlib --extern ip=E:\maidsafe\get_if_addrs\target\debug\deps\libip-02759db6b92ee1f9.rlib`
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
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 1, message: "Incorrect function." } }', ../src/libcore\result.rs:746
stack backtrace:
   0: 0x6b242ce8 - strncmp
   1: 0x6b2048a1 - strncmp
   2: 0x77d82e81 - strncmp
   3: 0x6b256bca - strncmp
   4: 0x6b2050b6 - strncmp
   5: 0x6e7df922 - strncmp
   6: 0x6e7d9f3e - strncmp
   7:   0x8fd8d2 - strncmp
   8: 0x6e7de038 - strncmp

Could not compile `get_if_addrs`.

Caused by:
  Process didn't exit successfully: `rustc src\lib.rs --crate-name get_if_addrs --crate-type lib -g --out-dir E:\maidsafe\get_if_addrs\target\debug --emit=dep-info,link -L dependency=E:\maidsafe\get_if_addrs\target\debug -L dependency=E:\maidsafe\get_if_addrs\target\debug\deps --extern c_linked_list=E:\maidsafe\get_if_addrs\target\debug\deps\libc_linked_list-e29420960369b25b.rlib --extern libc=E:\maidsafe\get_if_addrs\target\debug\deps\liblibc-6f18902dd8f75ffb.rlib --extern ip=E:\maidsafe\get_if_addrs\target\debug\deps\libip-02759db6b92ee1f9.rlib` (exit code: 101)

[michaelfairley]

I'm getting a similar ICE (Error { repr: Os { code: 1, message: "Incorrect function." } }) with 1.11 when compiling xml-rs. #29783 seems to be related, and like that reporter, I'm running Windows 7 32-bit within VirtualBox.

[michaelfairley]

Some more info after a few more hours trying to work around this:

• It occurs with windows 8 as well (again, 32-bit and in VirtualBox).
• I can only get it occur to when I'm building a project that's on a mapped shared folder from the host (which appears as a network drive to the guest).
• If I copy the contents of the shared folder to a folder on my C: drive, things build fine.
• If i subst the copied folder from the previous bullet to a new drive letter, things still build fine, somewhat ruling out "building on a weird drive letter" as the issue.

[michaelfairley]

I grabbed a stacktrace with gdb:

#0  0x67c1e320 in rust_panic ()
   from C:\Program Files\Rust stable GNU 1.11\bin\std-39b92f95.dll
#1  0x67c04c84 in std::panicking::rust_panic_with_hook::hd7b83626099d3416 ()
   from C:\Program Files\Rust stable GNU 1.11\bin\std-39b92f95.dll
#2  0x67c3fa88 in std::panicking::begin_panic::h941ea76fc945d925 ()
   from C:\Program Files\Rust stable GNU 1.11\bin\std-39b92f95.dll
#3  0x67c06d6d in std::panicking::begin_panic_fmt::h30280d4dd3f149f5 ()
   from C:\Program Files\Rust stable GNU 1.11\bin\std-39b92f95.dll
#4  0x67c3f82f in rust_begin_unwind ()
   from C:\Program Files\Rust stable GNU 1.11\bin\std-39b92f95.dll
#5  0x67c51fa8 in core::panicking::panic_fmt::h2d3cc8234dde51b4 ()
   from C:\Program Files\Rust stable GNU 1.11\bin\std-39b92f95.dll
#6  0x6ca3b2ab in _fu226___ZN4core6result13unwrap_failed10_FILE_LINE17h730ed9164be33e67E ()
   from C:\Program Files\Rust stable GNU 1.11\bin\rustc_metadata-39b92f95.dll
#7  0x6cae3e47 in _fu343___ZN38_$LT$core..option..Option$LT$T$GT$$GT$6unwrap14_MSG_FILE_LINE17hc89d807017dd066bE ()
   from C:\Program Files\Rust stable GNU 1.11\bin\rustc_metadata-39b92f95.dll
#8  0x6cac6160 in rustc_metadata::creader::CrateReader::load::hb86defd12ffcdae5 () from C:\Program Files\Rust stable GNU 1.11\bin\rustc_metadata-39b92f95.dll
#9  0x6cac9b7b in rustc_metadata::creader::CrateReader::read_extension_crate::h6101a5aa9052a0fc ()
   from C:\Program Files\Rust stable GNU 1.11\bin\rustc_metadata-39b92f95.dll
#10 0x6cacb3ad in rustc_metadata::creader::CrateReader::read_exported_macros::hd179a7d05e3b7c05 ()
   from C:\Program Files\Rust stable GNU 1.11\bin\rustc_metadata-39b92f95.dll
#11 0x6caf6133 in _fu888___ZN3std11collections4hash3map11RandomState3new4KEYS17hb806d9bac9a41080E ()
   from C:\Program Files\Rust stable GNU 1.11\bin\rustc_metadata-39b92f95.dll
#12 0x674f8d57 in _$LT$syntax..ext..expand..MacroExpander..load_macros..MacroLoadingVisitor$LT$$u27 $a$C$$u20$$u27$b$GT$$u20$as$u20$syntax..visit..Visitor$GT$::visit_item::h8628ee4498e5def8 ()
   from C:\Program Files\Rust stable GNU 1.11\bin\syntax-39b92f95.dll
#13 0x6753bb2e in syntax::ext::expand::expand_crate::h943e1e51f06dd940 ()
   from C:\Program Files\Rust stable GNU 1.11\bin\syntax-39b92f95.dll
#14 0x7044acac in _fu108___ZN5alloc7raw_vec11alloc_guard14_MSG_FILE_LINE17h0fd6f822bd86c07aE ()
   from C:\Program Files\Rust stable GNU 1.11\bin\rustc_driver-39b92f95.dll
#15 0x704439b5 in _fu478___ZN5rustc4util6common4time5DEPTH17h6eb268ad83e9cdadE ()
   from C:\Program Files\Rust stable GNU 1.11\bin\rustc_driver-39b92f95.dll
#16 0x704158db in rustc_driver::driver::compile_input::hdfe4405d66704c31 ()
   from C:\Program Files\Rust stable GNU 1.11\bin\rustc_driver-39b92f95.dll
#17 0x70406c2e in rustc_driver::run_compiler::h581448fb74257353 ()
   from C:\Program Files\Rust stable GNU 1.11\bin\rustc_driver-39b92f95.dll
#18 0x70403c0f in _fu2___ZN38_$LT$core..option..Option$LT$T$GT$$GT$6unwrap14_MSG_FILE_LINE17hc89d807017dd066bE ()
   from C:\Program Files\Rust stable GNU 1.11\bin\rustc_driver-39b92f95.dll
#19 0x67c4c50b in __rust_try ()
   from C:\Program Files\Rust stable GNU 1.11\bin\std-39b92f95.dll
#20 0x67c4c4a1 in __rust_maybe_catch_panic ()
   from C:\Program Files\Rust stable GNU 1.11\bin\std-39b92f95.dll
#21 0x70404795 in _fu46___ZN3std9panicking11PANIC_COUNT17h747ab620a51161d7E ()
   from C:\Program Files\Rust stable GNU 1.11\bin\rustc_driver-39b92f95.dll
#22 0x67c3bfa2 in std::sys::thread::Thread::new::thread_start::h7c59ebf0bbb78261 () from C:\Program Files\Rust stable GNU 1.11\bin\std-39b92f95.dll
#23 0x75404198 in KERNEL32!BaseThreadInitThunk ()
   from C:\Windows\system32\kernel32.dll
#24 0x7720445d in ?? ()
#25 0x7720442b in ?? ()
#26 0x00000000 in ?? ()
(gdb)

[retep998]

Yes, rustc is currently not robust with regards to network drives. They have weird quirks such as saying something was done before it was actually done, leading to fun race conditions that some software doesn't know how to deal with.

[michaelfairley]

Indeed. This particular error (Incorrect function.) seems to happen to VirtualBox shared folders when the guest tries to do certain things to a file too quickly or while the host is also accessing the same file.

Setting CARGO_TARGET_DIR to somewhere outside the shared folder is a reasonable (at least for me) workaround for now.

[canndrew]

I can only get it occur to when I'm building a project that's on a mapped shared folder from the host (which appears as a network drive to the guest).

This would have been the same thing happening to me then.

[cyplo]

As the reference issue got closed - do we know if this one is still a problem ? (don't have windows handy to check myself)

[steveklabnik]

Triage: i'm going to close this, as we haven't heard anything from the OP since 2016, and it seems that the original pr was merged in.