remote file lock issue causes a panic

[nacho319]

running on Mac OS 10.13.6 to a network file system hosted on FreeNAS via smbfs.

Compiling bedFilter v0.1.0 (/Volumes/3dPrint/bedFilter)
error: incremental compilation: could not create session directory lock file: Operation not supported (os error 45)

thread 'rustc' panicked at 'trying to get session directory from `IncrCompSession`: NotInitialized', compiler/rustc_session/src/session.rs:945:48
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

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/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.51.0 running on x86_64-apple-darwin

note: compiler flags: -C embed-bitcode=no -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

error: could not compile `bedFilter`

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

[nacho319]

Just in case the backtrace helps at all, I re-ran it with the backtrace enabled:

   Compiling bedFilter v0.1.0 (/Volumes/3dPrint/bedFilter)
error: incremental compilation: could not create session directory lock file: Operation not supported (os error 45)

thread 'rustc' panicked at 'trying to get session directory from `IncrCompSession`: NotInitialized', compiler/rustc_session/src/session.rs:945:48
stack backtrace:
   0: _rust_begin_unwind
   1: std::panicking::begin_panic_fmt
   2: rustc_session::session::Session::incr_comp_session_dir
   3: rustc_incremental::persist::fs::garbage_collect_session_directories
   4: rustc_session::utils::<impl rustc_session::session::Session>::time
   5: rustc_interface::passes::register_plugins
   6: rustc_interface::queries::Queries::register_plugins
   7: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
   8: rustc_span::with_source_map
   9: rustc_interface::interface::create_compiler_and_run
  10: rustc_span::with_session_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

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/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.51.0 running on x86_64-apple-darwin

note: compiler flags: -C embed-bitcode=no -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

error: could not compile `bedFilter`

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

[nacho319]

So I posted this from a MacOS client, but I also tried it via a FreeBSD machine. cargo didn't panic on the FreeBSD machine, but I did get a "no locks available" error with a graceful exit. The Mac was connecting to the file server via smbfs (its default) and the FreeBSD was NFSv3 mounting the same file share. I switched both the Mac and the FreeBSD machine to NFSv4 mount the share and now they can both compile. Maybe if they were both running NFS mounts or both running SMB mounts then locking would work. I suspect (since the locking regime between SMB and NFS aren't entirely compatible) that maybe FreeNAS was having issues with that.

The underlying lack of graceful exit on the Mac still exists when it can't get a file lock. But I solved the fundamental issue on my infrastructure allowing network file locking to function properly.

[ehuss]

Thanks for the report! Incremental builds requiring working file locks is a known issue (#49773, #59224, #66513, #76251). I believe there are some limitations of smb on macOS. The compiler at least shouldn't panic.

Some workarounds are to use a target directory on the local filesystem, or disable incremental.

Since there are multiple issues for this, I'm going to close this as a duplicate of #59224 (which mentions macos).