`thread '<main>' has overflowed its stack`

[bvssvni]

Getting this on cargo update for https://github.com/pistondevelopers/piston-examples:

cargo 0.4.0-nightly (1b902d4 2015-08-03) (built 2015-08-03)

[alexcrichton]

What platform was this on? Also, you were using a nightly build, right?

There also doesn't seem to be a Cargo.lock inside that repository, so I can't reproduce (a normal cargo build doesn't do this). Do you have a Cargo.lock I could copy in though?

[bvssvni]

OSX 10.9.5

rustc 1.3.0-nightly (38517944f 2015-08-03)

Link to Cargo.lock https://gist.github.com/bvssvni/54ac9c648e9acf739f20

[bvssvni]

Seems to work with Rust 1.1:

cargo 0.2.0-nightly (a483581 2015-05-14) (built 2015-05-15)

[jyasskin]

With:

$ cargo --version
cargo 0.4.0 (dd114a4 2015-07-25) (built 2015-07-25)
$ rustc --version
rustc 1.1.0
$ cat Cargo.toml
[package]
name = "cargo-1875"
version = "0.1.0"

[dependencies]
hyper = "0.6"
regex = "0.1"
$ cat src/lib.rs
#[test]
fn it_works() {
}

and nothing else in the directory, on MacOS 10.10.4, I get:

$ cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`

thread '<main>' has overflowed its stack
Illegal instruction: 4

This still happens after I rm -rf ~/.cargo.

[jyasskin]

After building from git, the stack trace is a deep loop of:

    frame #367: 0x00000001001b4998 cargo`cargo::core::resolver::activate_deps(cx=0x1d1d1d1d1d1d1d1d, registry=&mut Registry at 0x00007fff5fbf10d8, parent=0x00000001024310f0, platform=Option<&str> at 0x00007fff5fbf10c0, deps=Iter<(&cargo::core::dependency::Dependency, collections::vec::Vec<alloc::rc::Rc<cargo::core::summary::Summary>>, collections::vec::Vec<collections::string::String>)> at 0x00007fff5fbf10b0, cur=0, finished=&mut FnMut<(Box<cargo::core::resolver::Context>, &mut Registry)> at 0x00007fff5fbf1098) + 456 at mod.rs:323
    frame #368: 0x00000001001b108a cargo`cargo::core::resolver::activate(cx=0x1d1d1d1d1d1d1d1d, registry=&mut Registry at 0x00007fff5fbf16e0, parent=0x0000000102624900, method=Method at 0x00007fff5fbf16a8, finished=&mut FnMut<(Box<cargo::core::resolver::Context>, &mut Registry)> at 0x00007fff5fbf1698) + 3818 at mod.rs:293
    frame #369: 0x00000001001b5fcc cargo`cargo::core::resolver::activate_deps(cx=0x000000010247d300, registry=&mut Registry at 0x00007fff5fbf2458, parent=0x0000000102431030, platform=Option<&str> at 0x00007fff5fbf2440, deps=Iter<(&cargo::core::dependency::Dependency, collections::vec::Vec<alloc::rc::Rc<cargo::core::summary::Summary>>, collections::vec::Vec<collections::string::String>)> at 0x00007fff5fbf2430, cur=0, finished=&mut FnMut<(Box<cargo::core::resolver::Context>, &mut Registry)> at 0x00007fff5fbf2418) + 6140 at mod.rs:377
    frame #370: 0x00000001001b108a cargo`cargo::core::resolver::activate(cx=0x1d1d1d1d1d1d1d1d, registry=&mut Registry at 0x00007fff5fbf2a60, parent=0x000000010266de50, method=Method at 0x00007fff5fbf2a28, finished=&mut FnMut<(Box<cargo::core::resolver::Context>, &mut Registry)> at 0x00007fff5fbf2a18) + 3818 at mod.rs:293

Some of these are tail-calls, so would do better with optimization, but you'll still be sacrificing your ability to run cargo in debug mode where tail-call opt is generally off, and even with optimization there's a loop between:

frame #322: 0x00000001001b108a cargo`cargo::core::resolver::activate(cx=0x1d1d1d1d1d1d1d1d, registry=&mut Registry at 0x00007fff5fbe5a40, parent=0x00000001026fb438, method=Method at 0x00007fff5fbe5a08, finished=&mut FnMut<(Box<cargo::core::resolver::Context>, &mut Registry)> at 0x00007fff5fbe59f8) + 3818 at mod.rs:293
   290          Method::Everything => None,
   291      };
   292
-> 293      activate_deps(cx, registry, parent, platform, deps.iter(), 0,
   294                    &mut |mut cx, registry| {
   295          cx.visited.remove(id);
   296          finished(cx, registry)
(lldb) down
frame #321: 0x00000001001b5fcc cargo`cargo::core::resolver::activate_deps(cx=0x000000010247d900, registry=&mut Registry at 0x00007fff5fbe5438, parent=0x00000001024311b0, platform=Option<&str> at 0x00007fff5fbe5420, deps=Iter<(&cargo::core::dependency::Dependency, collections::vec::Vec<alloc::rc::Rc<cargo::core::summary::Summary>>, collections::vec::Vec<collections::string::String>)> at 0x00007fff5fbe5410, cur=0, finished=&mut FnMut<(Box<cargo::core::resolver::Context>, &mut Registry)> at 0x00007fff5fbe53f8) + 6140 at mod.rs:377
   374          if !dep.is_transitive() {
   375              my_cx.visited.clear();
   376          }
-> 377          let my_cx = try!(activate(my_cx, registry, candidate, method,
   378                                    &mut |cx, registry| {
   379              activate_deps(cx, registry, parent, platform, deps.clone(), cur + 1,
   380                            finished)

(Why aren't Rust/LLVM managing to tail-optimize the cargo/core/resolver/mod.rs:293 call in tail position?)

[tomjakubowski]

Is it possible to create a new stable release (1.2.1) with this fix backported? It makes the stable distribution impossible to use with several popular crates (glium, this hyper/regex combo).

[tomjakubowski]

Never mind, I think I misunderstood how releases are done (rustc is versioned separately from cargo). But if one were to run rustup.sh to get the latest stable distribution, would that install a Cargo with this fix included?

edit: erm, I guess that the stable rust installer for OS X also comes with Cargo, although it's a quite old one (cargo 0.4.0-nightly (15b497b 2015-07-08) (built 2015-07-09)).

[SimonSapin]

The default distribution of of Rust comes with a specific version of rustc paired with a specific version of cargo. You can upgrade them separately, but I don’t know if it’ll work. For example, #1830 makes Cargo pass --cap-lints=allow to rustc, but I don’t know what happens with older rustc versions that don’t support that option. Try it?