Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggest RUST_MIN_STACK workaround on overflow #122847

Conversation

workingjubilee
Copy link
Member

For some Rust crates, like p384, we can't do a whole lot about it even if the stack overflow is reported like in #122357 because the problem may be inside LLVM or another codegen backend. We can, however, suggest people set a new RUST_MIN_STACK value while handling the SIGSEGV, as that stack-setting will carry forward into the dylib.

As a bonus, this also leads to cleaning up the stack-setting code a bit.

@rustbot
Copy link
Collaborator

rustbot commented Mar 21, 2024

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 21, 2024
@TaKO8Ki
Copy link
Member

TaKO8Ki commented Mar 22, 2024

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Mar 22, 2024

📌 Commit 5425338 has been approved by TaKO8Ki

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 22, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 22, 2024
…ack-workaround-on-overflow, r=TaKO8Ki

Suggest `RUST_MIN_STACK` workaround on overflow

For some Rust crates, like p384, we can't do a whole lot about it even if the stack overflow is reported like in rust-lang#122357 because the problem may be inside LLVM or another codegen backend. We can, however, suggest people set a new `RUST_MIN_STACK` value while handling the SIGSEGV, as that stack-setting will carry forward into the dylib.

As a bonus, this also leads to cleaning up the stack-setting code a bit.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 22, 2024
…ack-workaround-on-overflow, r=TaKO8Ki

Suggest `RUST_MIN_STACK` workaround on overflow

For some Rust crates, like p384, we can't do a whole lot about it even if the stack overflow is reported like in rust-lang#122357 because the problem may be inside LLVM or another codegen backend. We can, however, suggest people set a new `RUST_MIN_STACK` value while handling the SIGSEGV, as that stack-setting will carry forward into the dylib.

As a bonus, this also leads to cleaning up the stack-setting code a bit.
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 22, 2024
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#121619 (Experimental feature postfix match)
 - rust-lang#122370 (Gracefully handle `AnonConst` in `diagnostic_hir_wf_check()`)
 - rust-lang#122537 (interpret/allocation: fix aliasing issue in interpreter and refactor getters a bit)
 - rust-lang#122542 (coverage: Clean up marker statements that aren't needed later)
 - rust-lang#122800 (Add `NonNull::<[T]>::is_empty`.)
 - rust-lang#122820 (Stop using `<DefId as Ord>` in various diagnostic situations)
 - rust-lang#122847 (Suggest `RUST_MIN_STACK` workaround on overflow)
 - rust-lang#122855 (Fix Itanium mangling usizes)
 - rust-lang#122863 (add more ice tests )

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit b317cda into rust-lang:master Mar 22, 2024
11 checks passed
@rustbot rustbot added this to the 1.79.0 milestone Mar 22, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 22, 2024
Rollup merge of rust-lang#122847 - workingjubilee:suggest-rust-min-stack-workaround-on-overflow, r=TaKO8Ki

Suggest `RUST_MIN_STACK` workaround on overflow

For some Rust crates, like p384, we can't do a whole lot about it even if the stack overflow is reported like in rust-lang#122357 because the problem may be inside LLVM or another codegen backend. We can, however, suggest people set a new `RUST_MIN_STACK` value while handling the SIGSEGV, as that stack-setting will carry forward into the dylib.

As a bonus, this also leads to cleaning up the stack-setting code a bit.
@workingjubilee workingjubilee deleted the suggest-rust-min-stack-workaround-on-overflow branch March 22, 2024 17:23
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 4, 2024
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#121619 (Experimental feature postfix match)
 - rust-lang#122370 (Gracefully handle `AnonConst` in `diagnostic_hir_wf_check()`)
 - rust-lang#122537 (interpret/allocation: fix aliasing issue in interpreter and refactor getters a bit)
 - rust-lang#122542 (coverage: Clean up marker statements that aren't needed later)
 - rust-lang#122800 (Add `NonNull::<[T]>::is_empty`.)
 - rust-lang#122820 (Stop using `<DefId as Ord>` in various diagnostic situations)
 - rust-lang#122847 (Suggest `RUST_MIN_STACK` workaround on overflow)
 - rust-lang#122855 (Fix Itanium mangling usizes)
 - rust-lang#122863 (add more ice tests )

r? `@ghost`
`@rustbot` modify labels: rollup
Comment on lines +57 to +58
env::var_os("RUST_MIN_STACK")
.map(|os_str| os_str.to_string_lossy().into_owned())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid the into_owned() cloning:

Suggested change
env::var_os("RUST_MIN_STACK")
.map(|os_str| os_str.to_string_lossy().into_owned())
env::var_os("RUST_MIN_STACK")
.as_ref()
.map(|os_str| os_str.to_string_lossy())

Comment on lines +60 to +61
.filter(|s| s.trim() != "")
.map(|s| s.trim().parse::<usize>().unwrap())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to .unwrap() here? The UX on a bad RUST_MIN_STACK wouldn't be great. Given the usage of .filter() and .unwrap_or() outside of this, does it mean we want to silently ignore bad values (e.g., RUST_MIN_STACK=" ")?

Suggested change
.filter(|s| s.trim() != "")
.map(|s| s.trim().parse::<usize>().unwrap())
.and_then(|s| s.trim().parse::<usize>().ok())

or, if we don't want to silently ignore the erroneous value:

Suggested change
.filter(|s| s.trim() != "")
.map(|s| s.trim().parse::<usize>().unwrap())
.map(|s| s.trim().parse::<usize>().expect("`RUST_MIN_STACK` env var to be a `usize`))

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thread 'main' panicked at compiler/rustc_interface/src/util.rs:61:48:
called Result::unwrap() on an Err value: ParseIntError { kind: InvalidDigit }

Huh, I thought for some reason it'd look better than that.

@danielhenrymantilla
Copy link
Contributor

Whoops didn't see the PR was already merged 😆

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request May 20, 2024
…t, r=compiler-errors

defrost `RUST_MIN_STACK=ice rustc hello.rs`

I didn't think too hard about testing my previous PR rust-lang#122847 which makes our stack overflow handler assist people in discovering the `RUST_MIN_STACK` variable (which apparently is surprisingly useful for Really Big codebases). After it was merged, some useful comments left in a drive-by review led me to discover I had added an ICE. This reworks the code a bit to explain the rationale, remove the ICE that I introduced, and properly test one of the diagnostics.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request May 20, 2024
Rollup merge of rust-lang#125302 - workingjubilee:prefer-my-stack-neat, r=compiler-errors

defrost `RUST_MIN_STACK=ice rustc hello.rs`

I didn't think too hard about testing my previous PR rust-lang#122847 which makes our stack overflow handler assist people in discovering the `RUST_MIN_STACK` variable (which apparently is surprisingly useful for Really Big codebases). After it was merged, some useful comments left in a drive-by review led me to discover I had added an ICE. This reworks the code a bit to explain the rationale, remove the ICE that I introduced, and properly test one of the diagnostics.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants