Stack overflow in thread local's drop rendered as a segmentation fault.

[jswrenn]

Code

pub fn main() {
    struct RecursiveDrop;

    impl Drop for RecursiveDrop {
        fn drop(&mut self) {
            let _ = RecursiveDrop;
        }
    }

    thread_local!(static LOCAL: RecursiveDrop = const { RecursiveDrop });

    LOCAL.with(|_| {});
}

Current output

Segmentation fault (core dumped)

Desired output

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
Aborted (core dumped)

Rationale and extra context

This should encounter a guard page and produce the expected diagnostic, but it does not.

rustc --version --verbose:

rustc 1.70.0-nightly (44f518058 2023-03-20)
binary: rustc
commit-hash: 44f5180584404d18058cbbf224c55255db4fdcbb
commit-date: 2023-03-20
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 15.0.7

[cuviper]

Encountering a guard page is a SIGSEGV, as that handler shows, but the tricky question is whether that code correctly identifies it as such, especially with kernel-managed stack growth on the main thread. Can you run this in GDB and see a backtrace? It would also help to have info registers and info proc mappings.

[workingjubilee]

Technically #111272 is a duplicate of this issue but that one managed to have much more data and discussion in it so I am closing this one instead.