You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A-runtimeArea: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflowsC-bugCategory: This is a bug.T-libsRelevant to the library team, which will review and decide on the PR/issue.
SIGSEGV's are not exclusive to access violations, they can also be generated using raise or kill. Rust's stack overflow handler works by testing whether the address reported in the signal information is within the guard page range, and aborting the process along with a helpful message if so. If the address is outside of the guard page range, the handler uninstalls itself and returns with the intention of running faulty instructions again (which will lead to the default SIGSEGV behaviour occurring, e.g. a core dump on Linux). For SIGSEGVs not caused by access violations however, the process won't be aborted and execution will continue normally. Further stack overflows will however not cause the handler to be run.
A possible fix would be to re-raise the signal from the signal handler if it originates from a non-access-violation (by inspecting the si_code), but that would corrupt the information associated with the signal and might thus hinder debugging.
The text was updated successfully, but these errors were encountered:
joboet
added
A-runtime
Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
C-bug
Category: This is a bug.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
labels
May 5, 2025
A-runtimeArea: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflowsC-bugCategory: This is a bug.T-libsRelevant to the library team, which will review and decide on the PR/issue.
SIGSEGV's are not exclusive to access violations, they can also be generated using raise or kill. Rust's stack overflow handler works by testing whether the address reported in the signal information is within the guard page range, and aborting the process along with a helpful message if so. If the address is outside of the guard page range, the handler uninstalls itself and returns with the intention of running faulty instructions again (which will lead to the default SIGSEGV behaviour occurring, e.g. a core dump on Linux). For SIGSEGVs not caused by access violations however, the process won't be aborted and execution will continue normally. Further stack overflows will however not cause the handler to be run.
A possible fix would be to re-raise the signal from the signal handler if it originates from a non-access-violation (by inspecting the
si_code
), but that would corrupt the information associated with the signal and might thus hinder debugging.The text was updated successfully, but these errors were encountered: