`_Unwind_GetIP` returns `0x0`, and then jumps to it.
In certain cases (I'm not sure exactly which), _Unwind_GetIP inside of _Unwind_Backtrace is returning a null pointer, and then jumping to it after the callback completes. This is my code:
fn stack_trace() -> heapless::Vec<usize, 512> {
extern "C" fn callback(
unwind_ctx: &unwinding::abi::UnwindContext<'_>,
arg: *mut core::ffi::c_void,
) -> unwinding::abi::UnwindReasonCode {
let data = unsafe { &mut *arg.cast::<heapless::Vec<usize, 512>>() };
let _ = data.push(_Unwind_GetIP(unwind_ctx));
unwinding::abi::UnwindReasonCode::NO_REASON
}
let mut trace = heapless::Vec::new();
_Unwind_Backtrace(callback, core::ptr::addr_of_mut!(trace).cast());
trace
}
It's pretty much copied from panic_handler.rs, but pushed to a vec instead of immediately printed.
An example panic results in:
[ERROR] (panic) Panic! panicked at src/init.rs:148:5:
│ oops
│
│ Stack trace:
│ 4: 0xffffffff80002eec
│ 3: 0xffffffff8001d338
│ 2: 0xffffffff80007804
│ 1: 0xffffffff800074dc
│ 0: 0x0000000000000000
Followed by a prefetch data abort when trying to read from 0x0.
That's interesting, Frame::from_context should return None when IP is 0, and that'll be treated as end of frame. Would you be able to share more details about architecture, how things are compiled, etc?
Ah, I forgot those. This is aarch64, running unwinding from latest git.
rustc 1.80.0-nightly (804421dff 2024-06-07)
binary: rustc
commit-hash: 804421dff5542c9c7da5c60257b5dbc849719505
commit-date: 2024-06-07
host: aarch64-apple-darwin
release: 1.80.0-nightly
LLVM version: 18.1.7
and the target.json:
{
"abi": "softfloat",
"arch": "aarch64",
"crt-objects-fallback": "false",
"data-layout": "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128",
"disable-redzone": true,
"features": "+v8a,+strict-align,-neon,-fp-armv8",
"linker": "rust-lld",
"linker-flavor": "gnu-lld",
"llvm-target": "aarch64-unknown-none",
"max-atomic-width": 128,
"panic-strategy": "unwind",
"relocation-model": "pic",
"target-pointer-width": "64"
}
Could you provide a MCVE?
You could see if it also happens on the existing example. Otherwise, I can try I guess, but it might be long.