Skip to content

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
Collaborator

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
@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