rust-lang / rust-lang/backtrace-rs
Backtracing after stack overflow does not work on macOS
Open
Nobody has claimed this yet.
enhancement
help wanted
OS-macos
- Dominant language
- Rust
- Stars
- 628
- Forks
- 291
- PR merge metrics
- No merged PRs in 30d
Description
I'm trying to get a backtrace from a SIGSEGV caused by stack overflow (hitting guard page). It seems that this is not working on macOS.
My reproduction case:
use backtrace::Backtrace;
use std::{mem, ptr};
#[inline(never)]
fn f(x: i32) -> i32 {
if x == 0 || x == 1 {
1
} else {
f(x - 1) + f(x - 2)
}
}
fn main() {
unsafe {
let mut handler: libc::sigaction = mem::zeroed();
handler.sa_flags = libc::SA_ONSTACK;
handler.sa_sigaction = trap_handler as usize;
libc::sigemptyset(&mut handler.sa_mask);
assert_eq!(libc::sigaction(libc::SIGSEGV, &handler, ptr::null_mut()), 0);
// Backtracing from a normal SIGSEGV works
//println!("Before invalid write");
//ptr::write_volatile(0 as *mut u32, 0);
//println!("After invalid write");
// Backtracing from a stack overflow crashes
println!("Before stack overflow");
println!("{}", f(0xfffffff));
println!("After stack overflow");
}
}
unsafe extern "C" fn trap_handler(
_: libc::c_int
) {
println!("Backtrace begin");
let backtrace = Backtrace::new_unresolved();
println!("Backtrace result: {:?}", backtrace);
}
Output:
% ./target/release/backtrace-stackoverflow-bug
Before stack overflow
Backtrace begin
zsh: segmentation fault ./target/release/backtrace-stackoverflow-bug
Rust version:
rustc 1.46.0-nightly (16957bd4d 2020-06-30)
binary: rustc
commit-hash: 16957bd4d3a5377263f76ed74c572aad8e4b7e59
commit-date: 2020-06-30
host: x86_64-apple-darwin
release: 1.46.0-nightly
LLVM version: 10.0
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the macOS reproduction and the call to Backtrace::new_unresolved() inside trap_handler, comparing it with the normal SIGSEGV case shown in the issue. Investigate why stack-overflow handling fails after “Backtrace begin”; done means the supplied reproduction produces a backtrace instead of crashing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- macos, rust
- Domain
- devtools, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100