Run cargo with a large stack #1908
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There have been a number of reports of Cargo triggering a stack overflow in the algorithm implemented in `cargo::core::resolve`, and although many attempts have been made to reduce the stack space of the two relevant recursive functions it seems likely that this will not always be enough. For now, before moving the recursion to the heap manually, spawn the main thread with a large stack (e.g. mirror what the compiler does) to ensure that the same scenarios happen across platforms at least. Currently on my machine I get a 2MB stack on Linux and a 512K stack on OSX, so bumping this up to 8MB should be more than enough for the recursion in this algorithm. I also hope that with nonzeroing drop a few of the recursive calls will be able to become tail recursive, which should also help with stack space! Closes rust-lang#1897
|
r? @huonw (rust_highfive has picked a reviewer for you, use r? to override) |
|
I built Cargo on a mac with this PR and managed to build Servo with it. Thanks Alex! |
|
Travis & appveyor both failed? r=me if they're spurious. |
|
@bors: r=huonw Yeah those were fixed in the "update deps" PR |
|
📌 Commit 0139707 has been approved by |
bors
added a commit
that referenced
this pull request
Aug 17, 2015
There have been a number of reports of Cargo triggering a stack overflow in the algorithm implemented in `cargo::core::resolve`, and although many attempts have been made to reduce the stack space of the two relevant recursive functions it seems likely that this will not always be enough. For now, before moving the recursion to the heap manually, spawn the main thread with a large stack (e.g. mirror what the compiler does) to ensure that the same scenarios happen across platforms at least. Currently on my machine I get a 2MB stack on Linux and a 512K stack on OSX, so bumping this up to 8MB should be more than enough for the recursion in this algorithm. I also hope that with nonzeroing drop a few of the recursive calls will be able to become tail recursive, which should also help with stack space! Closes #1897
|
☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There have been a number of reports of Cargo triggering a stack overflow in the
algorithm implemented in
cargo::core::resolve, and although many attempts havebeen made to reduce the stack space of the two relevant recursive functions it
seems likely that this will not always be enough. For now, before moving the
recursion to the heap manually, spawn the main thread with a large stack (e.g.
mirror what the compiler does) to ensure that the same scenarios happen across
platforms at least.
Currently on my machine I get a 2MB stack on Linux and a 512K stack on OSX, so
bumping this up to 8MB should be more than enough for the recursion in this
algorithm. I also hope that with nonzeroing drop a few of the recursive calls
will be able to become tail recursive, which should also help with stack space!
Closes #1897