Incremental compilation ICEs on Windows in file systems that don’t support file locking

[chris-morgan]

Put a bunch of Rust code with dependencies on WSL in Windows 10, and try to compile it using Rust on the Windows side (so that the working directory will start with \\wsl$\), and incremental compilation falls over.

In order to reproduce this with Cargo, you must include the patch in rust-lang/cargo#7602, or else rust-lang/cargo#7511 (which basically corresponds to this report) will have Cargo fail before ever invoking rustc. (That fix has now landed.)

The important part of the cargo build output, with RUST_BACKTRACE=full:

error: incremental compilation: could not create session directory lock file: Incorrect function. (os error 1)

thread 'rustc' panicked at 'src\librustc\session\mod.rs:747: trying to get session directory from `IncrCompSession`: NotInitialized', src\librustc\util\bug.rs:37:26
stack backtrace:
   0:     0x7ff99dbd5679 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h899d23bfe202712f
   1:     0x7ff99dc0394b - core::fmt::write::ha832d1e3dd49bce5
   2:     0x7ff99dbc8b24 - <std::io::IoSliceMut as core::fmt::Debug>::fmt::h1e6e4d8d4f909cb7
   3:     0x7ff99dbd9c89 - std::panicking::take_hook::h236b2dc73ce544c4
   4:     0x7ff99dbd98dc - std::panicking::take_hook::h236b2dc73ce544c4
   5:     0x7ff983d6e8a4 - rustc_driver::report_ice::h80acc652833bba74
   6:     0x7ff99dbda501 - std::panicking::rust_panic_with_hook::h5faffc2c59c1b157
   7:     0x7ff985633fc7 - <rustc::util::common::QueryMsg as core::fmt::Debug>::fmt::h230b17a967680a02
   8:     0x7ff985105c06 - rustc::util::bug::bug_fmt::h9548574a5fdef226
   9:     0x7ff9851054e6 - <rustc::ty::trait_def::TraitImpls as rustc_data_structures::stable_hasher::HashStable<rustc::ich::hcx::StableHashingContext>>::hash_stable::ha9e5ac0ae7931938
  10:     0x7ff985105422 - <rustc::ty::trait_def::TraitImpls as rustc_data_structures::stable_hasher::HashStable<rustc::ich::hcx::StableHashingContext>>::hash_stable::ha9e5ac0ae7931938
  11:     0x7ff98510549a - <rustc::ty::trait_def::TraitImpls as rustc_data_structures::stable_hasher::HashStable<rustc::ich::hcx::StableHashingContext>>::hash_stable::ha9e5ac0ae7931938
  12:     0x7ff985105b3f - rustc::util::bug::bug_fmt::h9548574a5fdef226
  13:     0x7ff985105a9d - rustc::util::bug::bug_fmt::h9548574a5fdef226
  14:     0x7ff9852855f3 - rustc::session::Session::incr_comp_session_dir::h9c1ca88aac4438d7
  15:     0x7ff984a8fc2f - rustc_incremental::persist::fs::garbage_collect_session_directories::hedbe388c2156d39b
  16:     0x7ff983e5c5b0 - rustc_interface::passes::BoxedResolver::to_resolver_outputs::h8314aeeb32c17279
  17:     0x7ff983e5b7e3 - rustc_interface::passes::BoxedResolver::to_resolver_outputs::h8314aeeb32c17279
  18:     0x7ff983dff55d - <rustc_interface::proc_macro_decls::Finder as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_item::h5a0059c91c10947c
  19:     0x7ff983dc720a - rustc_interface::queries::<impl rustc_interface::interface::Compiler>::register_plugins::h70c68ec133e4ab7f
  20:     0x7ff983d1b365 - rustc_driver::pretty::print_after_hir_lowering::h97387ad5a1ee5b66
  21:     0x7ff983d26d16 - <syntax_pos::symbol::SymbolStr as core::fmt::Display>::fmt::h647f8f2f67bfb57a
  22:     0x7ff983d2c51f - <syntax_pos::symbol::SymbolStr as core::fmt::Display>::fmt::h647f8f2f67bfb57a
  23:     0x7ff983d2d6e6 - <syntax_pos::symbol::SymbolStr as core::fmt::Display>::fmt::h647f8f2f67bfb57a
  24:     0x7ff99dbec052 - _rust_maybe_catch_panic
  25:     0x7ff983d2ed02 - <syntax_pos::symbol::SymbolStr as core::fmt::Display>::fmt::h647f8f2f67bfb57a
  26:     0x7ff99dbb7ab7 - ZN244_$LT$std..error..$LT$impl$u20$core..convert..From$LT$alloc..string..String$GT$$u20$for$u20$alloc..boxed..Box$LT$dyn$u20$std..error..Error$u2b$core..marker..Sync$u2b$core..marker..Send$GT$$GT$..from..StringError$u20$as$u20$core..fmt..Display$GT$3fmt17
  27:     0x7ff99dbe9917 - std::sys::windows::thread::Thread::new::h4b7683e858c32090
  28:     0x7ff9dbf36fd4 - BaseThreadInitThunk
  29:     0x7ff9dde66231 - RtlUserThreadStart

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.41.0-nightly (0f0c640e0 2019-11-17) running on x86_64-pc-windows-msvc

note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
error: aborting due to previous error

I was compiling the cpal crate with the working directory \\wsl$\arch\home\me\code\cpal, using cargo build. I think anything with a few dependencies will hit this.

I haven’t done any code diving at this time, but I imagine the patch I applied to Cargo, rust-lang/cargo#7602, may be useful reference material.

[leo60228]

I think this could be fixed by changing https://github.com/rust-lang/rust/blob/master/src/librustc_data_structures/flock.rs#L155-L162 to:

                if ret == 0 {
                    let err = io::Error::last_os_error();
                    debug!("failed acquiring file lock: {}", err);
                    Err(err)
                } else if ret == ERROR_INVALID_FUNCTION {
                    debug!("locking not supported");
                    Ok(Lock { _file: file })
                } else {
                    debug!("successfully acquired lock");
                    Ok(Lock { _file: file })
                }

[leo60228]

Note that cargo's implementation seems much more robust than rustc's. Perhaps they should be unified somehow?

[wulymammoth]

Encountered this issue on a virtual machine using Vagrant/VirtualBox:

error: incremental compilation: could not create session directory lock file: No locks available (os error 37)

thread 'rustc' panicked at 'trying to get session directory from \IncrCompSession`: NotInitialized', src/librustc_session/session.rs:690:48

VM
Linux version 4.17.14-2ep.el6.x86_64 (vagrant@<redacted>) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC)) #1 SMP Thu Aug 9 22:58:00 UTC 2018

My (host) machine
macOS 10.15.6 / Catalina (can build on macOS just fine)

@chris-morgan, thankfully, pointed out that it's related to this issue that he opened and the current work-around is to disable incremental compilation via environment variable

CARGO_INCREMENTAL=0

[TheButlah]

I think this is the same as #80027, which I have closed in favor of this. My link might provide an even easier way to reproduce. This bug still exists both on nightly and stable (as of 13 December, 2020)