Open Jake-Shadle opened 2 years ago
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).
Ahh interesting, maybe I shot myself in the foot, I changed the address used for testing segfault handling https://github.com/EmbarkStudios/crash-handling/blob/6ff595e0e809ab5028bf76d22c4fb036ed4ffa6e/sadness-generator/src/lib.rs#L122 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.
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.
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.
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.
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 asSIGSEGV
where it should be populated with the address. We supposedly? set the correct flags when installing the signal handler https://github.com/EmbarkStudios/crash-handling/blob/e6c580d1984c721936974d89ffd2fe3d9f135d4d/crash-handler/src/linux/state.rs#L234 but...maybe not?