`ssi_addr` missing on Linux

[Jake-Shadle]

For some reason, at least on my Linux system, the ssi_addr field in the siginfo sent to the signal handler is always 0, even for signals such as SIGSEGV where it should be populated with the address. We supposedly? set the correct flags when installing the signal handler

crash-handling/crash-handler/src/linux/state.rs

Line 234 in e6c580d

sa.sa_flags = libc::SA_ONSTACK | libc::SA_SIGINFO;

but...maybe not?

[gabrielesvelto]

I assume you mean si_addr. Those flags are sufficient, something odd must be going on if si_addr is 0 for SIGSEGV... unless you're on x86-64 and you're crash is hitting a non-canonical address (i.e. one with bits set above bit 48) in which case SIGSEGV delivers 0 in si_addr regardless of the actual address. Bug 1493342 on our tracker has info about the issue (and one of my colleagues is working on a solution inside rust-minidump).

[Jake-Shadle]

Ahh interesting, maybe I shot myself in the foot, I changed the address used for testing segfault handling

crash-handling/sadness-generator/src/lib.rs

Line 122 in 6ff595e

pub const SEGFAULT_ADDRESS: u64 = u64::MAX - ((u32::MAX >> 1) as u64) + 0x42;

to make it > u32::MAX to ensure that 64-bit addresses were being handled on macos, so maybe I need to tune it more carefully.

[gabrielesvelto]

Yes, that's definitely a non-canonical address because it has all the upper 16 bits set. Try (u32::MAX as u64) + 0x42 instead, or something similar that doesn't fit into 32 bits but doesn't go beyond bit 48.

[gabrielesvelto]

FYI rust-minidump now disassembles the crashing instruction and retrieves the address of the actual memory access in this scenario. The exception handler will still return the NULL pointer when hitting non-canonical address but the minidump should have the required information to recreate the real one.

[Jake-Shadle]

FWIW I have yet to see the kernel ever fill out this field, regardless of the instruction address so it's good that rust-minidump does that now.