`thread 'rustc' panicked at 'src/librustc/session/mod.rs:809` with clean `cargo new` project #59224

samuela · 2019-03-16T04:50:56Z

I just created a new project with cargo new rust-cli and then cd'ed into the directory and ran cargo build but I got this error:

rust-cli 🔥 RUST_BACKTRACE=full cargo build --verbose
   Compiling rust-cli v0.1.0 (/nu/skainswo/nuvemfs/packages/rust-cli)
     Running `rustc --edition=2018 --crate-name rust_cli src/main.rs --color always --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=2e59314f72051b97 -C extra-filename=-2e59314f72051b97 --out-dir /nu/skainswo/nuvemfs/packages/rust-cli/target/debug/deps -C incremental=/nu/skainswo/nuvemfs/packages/rust-cli/target/debug/incremental -L dependency=/nu/skainswo/nuvemfs/packages/rust-cli/target/debug/deps`
error: incremental compilation: could not create session directory lock file: Operation not supported (os error 45)

thread 'rustc' panicked at 'src/librustc/session/mod.rs:809: Trying to get session directory from IncrCompSession `NotInitialized`', src/librustc/util/bug.rs:37:26
stack backtrace:
   0:        0x107dff0c3 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h9a87463918f2aff9
   1:        0x107df7c8c - std::sys_common::backtrace::_print::h54740e69908f9100
   2:        0x107dfb671 - std::panicking::default_hook::{{closure}}::h519f1fd4b67636f1
   3:        0x107dfb377 - std::panicking::default_hook::h5442e3ae9abda811
   4:        0x106564e21 - rustc::util::common::panic_hook::he77624544de4249c
   5:        0x107dfbed1 - std::panicking::rust_panic_with_hook::h4a3495c63f64f755
   6:        0x1065b9464 - std::panicking::begin_panic::hdbbe973fbc593bde
   7:        0x1060fd2ee - rustc::util::bug::opt_span_bug_fmt::{{closure}}::hab4de751350b061f
   8:        0x1060fca79 - rustc::ty::context::tls::with_opt::{{closure}}::hf9789a4ca7b4602d
   9:        0x1060fca1a - rustc::ty::context::tls::with_context_opt::h31a8f07b2eede9b0
  10:        0x1060fca41 - rustc::ty::context::tls::with_opt::he5de36b9ad0ca1ee
  11:        0x1060fd224 - rustc::util::bug::opt_span_bug_fmt::hc498b6667031b6cf
  12:        0x1060fd171 - rustc::util::bug::bug_fmt::hfd92ab0e6a89baed
  13:        0x1060eb79c - rustc::session::Session::incr_comp_session_dir::hce2b9cc3469c48f8
  14:        0x104727819 - rustc_incremental::persist::fs::garbage_collect_session_directories::hf4763add12a9bfcd
  15:        0x103f88f16 - rustc_driver::driver::phase_2_configure_and_expand_inner::{{closure}}::h70a5aafbefa7a5e2
  16:        0x103f84a62 - rustc::util::common::time::hcc38f9c33ada75da
  17:        0x103fd8d14 - rustc_driver::driver::phase_2_configure_and_expand::h408abbdadb43a773
  18:        0x103fd5825 - rustc_driver::driver::compile_input::h0a81d2a90aae52be
  19:        0x103f4751e - rustc_driver::run_compiler_with_pool::h762933062fd399ae
  20:        0x103f532ae - <scoped_tls::ScopedKey<T>>::set::hbad459430e7ff417
  21:        0x103f46488 - rustc_driver::run_compiler::ha1900917d325f169
  22:        0x103f5346b - <scoped_tls::ScopedKey<T>>::set::hf6e550156f6dc0f3
  23:        0x103fb478d - std::sys_common::backtrace::__rust_begin_short_backtrace::hb4db181f859dd41a
  24:        0x107e0b7ce - __rust_maybe_catch_panic
  25:        0x103fcb62d - <F as alloc::boxed::FnBox<A>>::call_box::h54bd2886afe0d20a
  26:        0x107e0a71b - std::sys::unix::thread::Thread::new::thread_start::h2ccd51efe09a6d88
  27:     0x7fff633e5304 - _pthread_body
  28:     0x7fff633e826e - _pthread_start
query stack during panic:
end of query stack
error: aborting due to previous error


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.33.0 (2aa4c46cf 2019-02-28) running on x86_64-apple-darwin

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

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

error: Could not compile `rust-cli`.

Caused by:
  process didn't exit successfully: `rustc --edition=2018 --crate-name rust_cli src/main.rs --color always --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=2e59314f72051b97 -C extra-filename=-2e59314f72051b97 --out-dir /nu/skainswo/nuvemfs/packages/rust-cli/target/debug/deps -C incremental=/nu/skainswo/nuvemfs/packages/rust-cli/target/debug/incremental -L dependency=/nu/skainswo/nuvemfs/packages/rust-cli/target/debug/deps` (exit code: 101)

I made no changes to the generated project after running cargo new.

Meta

I'm on macOS 10.14.2.

rust-cli 🔥 rustc --version --verbose
rustc 1.33.0 (2aa4c46cf 2019-02-28)
binary: rustc
commit-hash: 2aa4c46cfdd726e97360c2734835aa3515e8c858
commit-date: 2019-02-28
host: x86_64-apple-darwin
release: 1.33.0
LLVM version: 8.0

The project lives on an SMB file share. No idea whether that's relevant, but it's the only slightly unorthodox bit of my setup.

The text was updated successfully, but these errors were encountered:

samuela · 2019-03-16T04:51:54Z

Problem does not exist when the project lives in the local filesystem.

Centril · 2019-03-16T06:59:24Z

Backtrace suggests issues with incremental? cc @Zoxc

hellow554 · 2019-03-18T07:51:34Z

Does not occur on windows. Neither on a attached network folder (assign it to a letter, e.g. W:) nor a "raw" shared folder.

Zoxc · 2019-03-18T08:01:48Z

I suspect this is due to older SMB versions (pre-3.0) not supporting locking files. Not sure why we need that though. cc @michaelwoerister

samuela · 2019-03-18T08:14:05Z

@Zoxc smbutil claims it's on 3.0, but I don't really trust macOS's SMB driver that much:

rustcli 🔥 smbutil statshares -a

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
skainswo                      
                              SERVER_NAME                   <...>.file.core.windows.net
                              USER_ID                       501
                              SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.0
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              SIGNING_REQUIRED              TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              DFS_SUPPORTED                 TRUE
                              FILE_LEASING_SUPPORTED        TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE
                              PERSISTENT_HANDLES_SUPPORTED  TRUE
                              DIR_LEASING_SUPPORTED         TRUE
                              ENCRYPTION_SUPPORTED          TRUE
                              SIGNING_ON                    TRUE

--------------------------------------------------------------------------------------------------

retep998 · 2019-03-18T23:52:55Z

Instead of using the lock file api, could we alternatively just open the file without FILE_SHARE_READ and FILE_SHARE_WRITE?

michaelwoerister · 2019-03-25T11:24:32Z

The lock files are how rustc coordinates multiple processes accessing the same incremental cache directory (although I don't remember that exact protocol off the top of my head). It's a known issue that this doesn't work well with some network file systems (NFS can run into this too, I think).

samuela · 2019-03-25T20:16:31Z

@michaelwoerister what about providing an option to move the cache and/or the lockfiles outside of the source directory? That would have the added benefit of improved performance on networked file systems.

michaelwoerister · 2019-03-26T08:11:17Z

Good thinking! As far as rustc is concerned the cache directory can be freely chosen already -- so this is something would have to be implemented in Cargo.

samuela · 2019-04-01T23:49:28Z

For any future googlers who may stumble on this,

[build]
# Cargo doesn't support ~ expansion here.
target-dir = "/opt/my-special-target-dir"

in my-project/.cargo/config does the trick!

…tebank Don't panic when failing to initialize incremental directory. This removes a panic when rustc fails to initialize the incremental directory. This can commonly happen on various filesystems that don't support locking (often various network filesystems). Panics can be confusing and scary, and there are already plenty of issues reporting this. This has been panicking since 1.22 due to I think rust-lang#44502 which was a major rework of how things work. Previously, things were simpler and the [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.21.0/src/librustc_incremental/persist/load.rs#L43-L65) function would emit an error and then continue on without panicking. With 1.22, [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.22.0/src/librustc_incremental/persist/load.rs#L44) was changed so that it assumes it can load the data without errors. Today, the problem is that it calls [`prepare_session_directory`](https://github.com/rust-lang/rust/blob/fbf1b1a7193cda17008ab590e06ad28d9924023b/compiler/rustc_interface/src/passes.rs#L175-L179) and then immediately calls `garbage_collect_session_directories` which will panic since the session is `IncrCompSession::NotInitialized`. The solution here is to have `prepare_session_directory` return an error that must be handled so that compilation stops if it fails. Some other options: * Ignore directory lock failures. * Print a warning on directory lock failure, but otherwise continue with incremental enabled. * Print a warning on directory lock failure, and disable incremental. * Provide a different locking mechanism. Cargo ignores lock errors if locking is not supported, so that would be a precedent for the first option. These options would require quite a bit more changes, but I'm happy to entertain any of them, as I think they all have valid justifications. There is more discussion on the many issues where this is reported: rust-lang#49773, rust-lang#59224, rust-lang#66513, rust-lang#76251. I'm not sure if this can be considered closing any of those, though, since I think there is some value in discussing if there is a way to avoid the error altogether. But I think it would make sense to at least close all but one to consolidate them.

ehuss · 2021-05-29T22:35:56Z

#85698 has changed it so that rustc does not panic in this situation, but it will still generate an error.

I'm going to close this as a duplicate of #49773 to consolidate the issues related to session locking.

Centril added A-driver Area: rustc_driver that ties everything together into the `rustc` compiler I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ labels Mar 16, 2019

Centril added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 16, 2019

jonas-schievink added the C-bug Category: This is a bug. label Aug 6, 2019

ehuss mentioned this issue Apr 27, 2021

remote file lock issue causes a panic #84417

Closed

ehuss mentioned this issue May 25, 2021

Don't panic when failing to initialize incremental directory. #85698

Merged

ehuss closed this as completed May 29, 2021

ehuss mentioned this issue May 29, 2021

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

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`thread 'rustc' panicked at 'src/librustc/session/mod.rs:809` with clean `cargo new` project #59224

`thread 'rustc' panicked at 'src/librustc/session/mod.rs:809` with clean `cargo new` project #59224

samuela commented Mar 16, 2019

samuela commented Mar 16, 2019

Centril commented Mar 16, 2019

hellow554 commented Mar 18, 2019

Zoxc commented Mar 18, 2019

samuela commented Mar 18, 2019

retep998 commented Mar 18, 2019

michaelwoerister commented Mar 25, 2019

samuela commented Mar 25, 2019

michaelwoerister commented Mar 26, 2019

samuela commented Apr 1, 2019

ehuss commented May 29, 2021

thread 'rustc' panicked at 'src/librustc/session/mod.rs:809 with clean cargo new project #59224

thread 'rustc' panicked at 'src/librustc/session/mod.rs:809 with clean cargo new project #59224

Comments

samuela commented Mar 16, 2019

Meta

samuela commented Mar 16, 2019

Centril commented Mar 16, 2019

hellow554 commented Mar 18, 2019

Zoxc commented Mar 18, 2019

samuela commented Mar 18, 2019

retep998 commented Mar 18, 2019

michaelwoerister commented Mar 25, 2019

samuela commented Mar 25, 2019

michaelwoerister commented Mar 26, 2019

samuela commented Apr 1, 2019

ehuss commented May 29, 2021

`thread 'rustc' panicked at 'src/librustc/session/mod.rs:809` with clean `cargo new` project #59224

`thread 'rustc' panicked at 'src/librustc/session/mod.rs:809` with clean `cargo new` project #59224