cargo update hangs

[durka]

I've tried to minimize this but I haven't made any progress.

When I run cargo update, it seems to go forever (I let it go for 30 minutes with no output; it pegged a CPU but didn't allocate a significant amount of memory). I've tried breaking into it in a debugger and it's not always in the same place, but it's been in jemalloc or HashMap internals. I am not low on RAM.

Here's a gist of Cargo.toml and Cargo.lock. Cargo.toml looks weird because it was generated by cargo-outdated.

If I comment out the c_vec line in Cargo.toml, the update finishes in a couple of seconds. However, trimming down Cargo.toml and Cargo.lock to only mention c_vec also doesn't hang. I also tried bisecting by commenting out the first half of the dependencies list, and the second half, and neither hang. So it's some combinatorial interaction between c_vec and... some other crate(s) in the list!

[alexcrichton]

Could you try re-running with RUST_LOG=cargo::core::resolve,cargo::core::registry and gist the output?

[durka]

Here is the gzipped log after running for a few minutes. (Compression ratio 98.2 -- I think we have ourselves a loop!)

[durka]

The above log was generated by the cargo distributed with beta rustc, but nightly exhibits the same behavior.

[alexcrichton]

This may just be a resurfacing of #2090, what version of Cargo were you using?

[durka]

Hm, that was closed on 3/11 but I tried with cargo 0.12.0-nightly (6b98d1f 2016-07-04) and cargo 0.13.0-nightly (4e66190 2016-08-05). Should I try with a git checkout?

[alexcrichton]

Nah the bugfix should be in there. The problem here is that Cargo's performing a search of the state space of the resolution graph, attempting to find a solution. It is in theory always making progress, but Cargo can get itself in to a rut where it spends a large amount of time trying to solve an unsolvable constraint.

The fix to #2090 was to prioritized super constrained crates (e.g. they'll prune out tons of solutions) and there's probably some other heuristic we can apply to fix this issue as well. Will need to investigate more to figure out what's going wrong though.

[durka]

Well, this Cargo.toml has no constraints at all (it's generated by cargo-outdated which is trying to find all possible updates). So the heuristic you mentioned wouldn't help.

[durka]

Is it really making progress? The log seems like it is looping, but there's so many crates that it's hard to see if it is actually moving around in the state space.

[terlar]

I get the same lockup, both when I tried to build xsv as well as ripgrep.

env RUST_LOG=cargo::core::resolve,cargo::core::registry cargo update
DEBUG:cargo::core::registry: load/missing  file:///tmp/makepkg/xsv/src/xsv-0.10.3
TRACE:cargo::core::resolver: resolve; summary=xsv v0.10.3 (file:///tmp/makepkg/xsv/src/xsv-0.10.3)
TRACE:cargo::core::resolver: activating xsv v0.10.3 (file:///tmp/makepkg/xsv/src/xsv-0.10.3)
DEBUG:cargo::core::registry: load/missing  registry https://github.com/rust-lang/crates.io-index
    Updating registry `https://github.com/rust-lang/crates.io-index`

cargo --version
cargo 0.12.0 (6b98d1f 2016-07-04)

[alexcrichton]

@terlar what was the Cargo.toml you were you using to generate the hang?

[terlar]

I can no longer reproduce this, I have upgraded cargo version, rust version and the repo version since then. The Cargo.toml should still be this one, since it hasn't changed since Aug 1, 2016.

[ararslan]

I was able to reproduce this on FreeBSD (12.0-CURRENT, x86-64) while attempting to build alacritty. The output of cargo update using @alexcrichton's suggested RUST_LOG, as well as the project's Cargo.toml and Cargo.lock, can be found here. I have Cargo 0.17.0, built 2017-04-08.

[heibor]

My macosx also hang when updating registry, my env is:

zhen@rust-to-c$ rustc --version --verbose
rustc 1.16.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-apple-darwin
release: 1.16.0
LLVM version: 3.9
zhen@rust-to-c$ cargo --version --verbose
cargo-0.17.0-dev (f9e5481 2017-03-03)
release: 0.17.0
commit-hash: f9e5481
commit-date: 2017-03-03
zhen@rust-to-c$

[phrohdoh]

I can reproduce this issue on macOS if I depend on either glium-sdl2 or winit (and possibly others but these are the only two I am sure of).

FWIW rust-sdl2 builds just fine on my system in ~11 seconds.

thill@tmba /Users/.../rust/openaoe $ rustc -vV
rustc 1.16.0 (30cf806ef 2017-03-10)
binary: rustc
commit-hash: 30cf806ef8881c41821fbd43e5cf3699c5290c16
commit-date: 2017-03-10
host: x86_64-apple-darwin
release: 1.16.0
LLVM version: 3.9

thill@tmba /Users/.../rust/openaoe $ cargo -vV
cargo-0.17.0-nightly (f9e5481 2017-03-03)
release: 0.17.0
commit-hash: f9e54817e53c7b9845cc7c1ede4c11e4d3e42e36
commit-date: 2017-03-03

thill@tmba /Users/.../rust/openaoe $ rustup -vV
rustup 1.2.0 (70faf07 2017-04-08)

thill@tmba /Users/.../rust/openaoe $ rustup toolchain list
stable-x86_64-apple-darwin (default)

[tailhook]

Just got this error on cargo 0.18.0 too. The thing that helped was manually updating all the dependencies in Cargo.toml.

[chriswakare]

Has this issue resurfaced?
I hit this one on Mac using rustc 1.19.0 and cargo 0.20.0

For now: killed the cargo process on my workstation to proceed

rust version:
rustc 1.19.0 (0ade33941 2017-07-17)
binary: rustc
commit-hash: 0ade339411587887bf01bcfa2e9ae4414c8900d4
commit-date: 2017-07-17
host: x86_64-apple-darwin
release: 1.19.0
LLVM version: 4.0

cargo version:
cargo 0.20.0 (a60d185 2017-07-13)
release: 0.20.0
commit-hash: a60d185
commit-date: 2017-07-13

[joedborg]

I'm getting the same as @chriswakare, on the same platform

[carols10cents]

I'm closing this as a duplicate of #4066, where we're consolidating on an effort to handle cases like this in a better way.

[johnfercher]

I'm having the same issue, with a lot of dependencies: cgmath, rand, time, regex.