Stack overflow (still) in `cargo build`

[SimonSapin]

When upgrading from Cargo nightly 2015-06-24 to 2015-08-05, Servo hit an issue with the same symptoms as #1875. On Mac (not Linux), cargo build ends with thread '<main>' has overflowed its stack after Updating lines but before any Compiling line in the output.

Upgrading to bfadd9a 2015-08-12, which as far as I can tell includes #1887 which closed #1875, does not fix this for Servo.

I haven’t managed to get a stack trace out of LLDB yet, but I can try some more if it helps.

[olsonjeffery]

Same here, on OSX Yosemite

bash-3.2$ cargo run
    Updating git repository `http://github.com/mattyhall/rs-tiled`
    Updating git repository `https://github.com/netvl/xml-rs.git`

thread '<main>' has overflowed its stack
Illegal instruction: 4
bash-3.2$ ls
#README.org#    Cargo.lock      Cargo.toml      Cargo.toml~     README.org      README.org~     content         src             target
bash-3.2$ cargo --version
cargo 0.4.0-nightly (c033770 2015-08-09) (built 2015-08-09)
bash-3.2$ rustc --version
rustc 1.4.0-nightly (5aca49c69 2015-08-10)
bash-3.2$

[olsonjeffery]

updating to latest nightly seems to have fixed this for me. hm.

[SimonSapin]

@olsonjeffery Which nightly is that? I’m still seeing the issue in 1f24be7 2015-08-13.

[olsonjeffery]

@SimonSapin happy to oblige! btw i'm on the nightly default in multirust.

bash-3.2$ rustc --version
rustc 1.4.0-nightly (e2bebf32f 2015-08-14)
bash-3.2$ cargo --version
cargo 0.5.0-nightly (1f24be7 2015-08-13)

As an aside, I've also noticed the issue was transient when I was experiencing it, and often seemed tied to when cargo was making a trip to github to get dependent crate info.

[alexcrichton]

The failure mode here is definitely dependent on the system and the size of the dependency graph in question. Servo, for example, has a very large dependency graph and OSX has a smaller default stack size than Linux, which explains the OSX-only failure for what looks like only Servo and also why I didn't catch it on Linux :).

I've submitted #1908 which should fix this for now.