sending a SIGSEGV via `kill` disables the stack overflow handler

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.

No file or test is named. Start by tracing Rust's stack overflow signal handler and how it distinguishes access violations from SIGSEGV sent by raise or kill, then determine behavior that preserves signal information while keeping later stack overflows handled. Done means externally generated SIGSEGVs no longer disable the stack overflow handler.