Cargo 0.21.0 Hanging while compiling without RUST_LOG=debug

[Ianleeclark]

On Freebsd 12.0 whenever attempting to cargo build or cargo run a semi brand-new cargo new test --bin project, the compilation will hang seemingly indefinitely (10+ minutes).

I did notice, however, if Cargo.lock and the target/ directory were both deleted while RUST_LOG=debug then the package would compile. If, however, either target/ or Cargo.lock were in the path, cargo would hang indefinitely.

Whenever attempting to build or run, I would get output like this:

ian@home ~/D/torrential> cargo build -v
   Compiling torrential v0.1.0 (file:///usr/home/ian/Development/torrential)
     Running `rustc --crate-name torrential src/main.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=b0bc5ad4bb1a8134 -C extra-filename=-b0bc5ad4bb1a8134 --out-dir /usr/home/ian/Development/torrential/target/debug/deps -L dependency=/usr/home/ian/Development/torrential/target/debug/deps`

which is where it would hang.

If attempting to build with RUST_LOG=debug, it would hang around:

Stability interner: #3
Layout interner: #41
INFO:rustc_metadata::cstore: topological ordering: [CrateNum(2), CrateNum(5), CrateNum(4), CrateNum(7), CrateNum(8), CrateNum(11), CrateNum(6), CrateNum(10), CrateNum(3), CrateNum(9), CrateNum(1)]
INFO:rustc_metadata::cstore: topological ordering: [CrateNum(2), CrateNum(5), CrateNum(4), CrateNum(7), CrateNum(8), CrateNum(11), CrateNum(6), CrateNum(10), CrateNum(3), CrateNum(9), CrateNum(1)]
INFO:rustc_metadata::cstore: topological ordering: [CrateNum(2), CrateNum(5), CrateNum(4), CrateNum(7), CrateNum(8), CrateNum(11), CrateNum(6), CrateNum(10), CrateNum(3), CrateNum(9), CrateNum(1)]

I'm using cargo 0.21.0 (5b4b8b2ae 2017-08-12)

If any other questions are needing to be answered to shed some light, just let me know and I'd be happy to supply further info!

Thanks!

[lukaslueg]

Rust on FreeBSD 12 has some libc-related problems, which is probably what's going on here. There are rust-builds being posted in rust-lang/rust#42681, maybe you could try building cargo with those and then try compiling your crate. We are probably out of luck with debugging Cargo as long as Rust itself is unstable on FreeBSD 12.

[lukaslueg]

rust-lang/rust#44433 is probably what's going on here.

[Ianleeclark]

@lukaslueg I don't doubt these in the slightest, but the most confusing part to me was this: why would the project compile whenever I removed the Cargo.lock? Whenever I looked at the Cargo.lock file, it seemed very innocuous and nothing arch specific, compiler hints, &c.

Even with RUST_LOG=debug, the compiler could hang, so the title of this issue may not necessarily best reflect what was happening.

[lukaslueg]

Different code paths may or may not get exposed to what is essentially undefined behavior. One can be happy to get a crash right away in such situations.

My point being that there is little use to actually debug this situation in Cargo, as long as the implementation of stdlib can't be trusted. I'm afraid we have to wait for rust-lang/rust#44433 and rust-lang/rust#42681 to settle.

[Ianleeclark]

@lukaslueg Ahh, that makes sense. Guess it's back to ubuntu for me for the foreseeable future.

[alexcrichton]

Closing as it sounds like this isn't Cargo-related