Large number of variables causes stack overflow (SIGSEGV) #122357
Comments
coder0xff
added
C-bug
rustbot
added
the
needs-triage
|
We've previously gotten reports of problems compiling this crate: While yes this is a compiler bug, making the compiler accept this code is likely way harder than adjusting If you're stuck because of this problem, you can probably run rustc with a bigger stack, using some combination of |
saethlin
added
A-LLVM
|
Agreed, I'm authoring a PR for p384 as a workaround. Perhaps this issue has value nonetheless due to the minimal reproduction, which appears to be novel amongst the other tickets, even llvm/llvm-project#76920 . Hopefully that makes it easier to address the root problem. |
jieyouxu
removed
the
needs-triage
workingjubilee
added
the
S-has-mcve
|
It is certainly a reproduction, for certain values of "minimal". Thank you! |
…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.
…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.
…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.
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.
While building the p384 crate on an experimental platform I encountered a consistent ICE. Initially, the problem seemed to be due to the experimental platform. However, identifying the minimal reproduction revealed that all rustc are likely impacted. Note that the top of the stack is inside LLVM. I wasn't sure whether to report here or in LLVM, but it's clear that the structure that's being passed into LLVM is causing it to recurse too deeply.
This issue is a follow-up to esp-rs#214.
Minimal Reproduction
Directory Structure
Contents of: Cargo.toml
Contents of: src/lib.rs
Meta
rustc --version --verbose:Error output
Backtrace
The text was updated successfully, but these errors were encountered: