Print address on SIGSEGV

[bjorn3]

It can be useful while debugging to find out if it is a null pointer / NonNull::dangling() pointer, or if it points just enough past the stack guard to not be detected as stack overflow.

It would also be useful to print if the access was a read, write or execution.

[bjorn3]

Also useful for aligned simd operations on unaligned address.

[Mark-Simulacrum]

To my knowledge, this is basically impossible? I believe it might be possible for us to install a signal handler on SIGSEGV and try and determine the incorrect dereference, but that seems... way too hard for Rust itself to do, nor something that we should do given our constraints.

[jonas-schievink]

I was working on a library to make something like this slightly more manageable, but didn't finish it. It is indeed a lot of work that is both operating system and architecture specific. It is technically possible though.

[bjorn3]

On linux siginfo_t->si_addr contains the address I think.

[Mark-Simulacrum]

To be clear, I meant "not really feasible for libstd to do" -- I think presumably this would be a good fit for a library outside std? I don't think there's anything in particular that ties this to std, and I'm basically arguing for "this does not belong in std"

[bjorn3]

There is already a SIGSEGV handler for stack overflows, so we could add something like:

// signum can be SIGSEGV or SIGBUS
rtprint!("signal {} for address 0x{:x}", signum, addr);

Before

rust/src/libstd/sys/unix/stack_overflow.rs

Line 95 in 695fe96

if guard.start <= addr && addr < guard.end {

for UNIX.

[nagisa]

My personal opinion is that we’ve made a mistake by not removing that handler[1] along with the rest of the morestack runtime before 1.0 cut and I would rather not see us commit another by adding more dubious functionality to it.

[1]: It is very much a best effort kind of thing and leads to invalid expectations. And also one of the few places where we fail to adhere to our “0-cost abstraction” goal.

[cuviper]

It is very much a best effort kind of thing and leads to invalid expectations.

It is just a heuristic, but without it I suspect we'd get a lot more bugs decrying segmentation faults in memory safe Rust. It's a better perspective to have diagnosed a stack overflow up front, even if we do so imperfectly.