-
Notifications
You must be signed in to change notification settings - Fork 13.4k
std: print a backtrace on stackoverflow #133170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,63 @@ | ||
use crate::ffi::{CStr, c_void}; | ||
use crate::mem::MaybeUninit; | ||
use crate::ptr; | ||
|
||
/// Prints the current backtrace, even in a signal handlers. | ||
/// | ||
/// Since `backtrace` requires locking and memory allocation, it cannot be used | ||
/// from inside a signal handler. Instead, this uses `libunwind` and `dladdr`, | ||
/// even though both of them are not guaranteed to be async-signal-safe, strictly | ||
/// speaking. However, at least LLVM's libunwind (used by macOS) has a [test] for | ||
/// unwinding in signal handlers, and `dladdr` is used by `backtrace_symbols_fd` | ||
/// in glibc, which it [documents] as async-signal-safe. | ||
/// | ||
/// In practice, this hack works well enough on GNU/Linux and macOS (and perhaps | ||
/// some other platforms). Realistically, the worst thing that can happen is that | ||
/// the stack overflow occurred inside the dynamic loaded while it holds some sort | ||
/// of lock, which could result in a deadlock if that happens in just the right | ||
/// moment. That's unlikely enough and not the *worst* thing to happen considering | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A deadlock may cause a service to hang for an extended period of time until a health check considers the service dead and forcefully restarts it rather than getting restarted immediately upon crashing. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And it could prevent a crash reporter from doing it's job. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I should have worded this differently. What I meant was just... the whole stack-overflow module is horribly unsound. Leaving aside the fact that signal handling itself isn't really specified in Rust anyway right now, this module contains awful crimes like The examples you point out are totally realistic. In fact, anything can occur, this is unsound after all. But because of the unlikelihood of actual misbehaviour, I assume that the crimes I committed here are acceptable. If not, there may be ways to work around the misbehaviour (for instance by doing |
||
/// that a stack overflow is already an unrecoverable error and most likely | ||
/// indicates a bug. | ||
/// | ||
/// [test]: https://github.com/llvm/llvm-project/blob/a6385a3fc8a88f092d07672210a1e773481c2919/libunwind/test/signal_unwind.pass.cpp | ||
/// [documents]: https://www.gnu.org/software/libc/manual/html_node/Backtraces.html#index-backtrace_005fsymbols_005ffd | ||
pub fn print() { | ||
extern "C" fn frame( | ||
ctx: *mut unwind::_Unwind_Context, | ||
arg: *mut c_void, | ||
) -> unwind::_Unwind_Reason_Code { | ||
let count = unsafe { &mut *(arg as *mut usize) }; | ||
let depth = *count; | ||
*count += 1; | ||
if depth > 128 { | ||
return unwind::_URC_NO_REASON; | ||
} | ||
|
||
let ip = unsafe { unwind::_Unwind_GetIP(ctx) }; | ||
let mut info = MaybeUninit::uninit(); | ||
let r = unsafe { libc::dladdr(ip.cast(), info.as_mut_ptr()) }; | ||
if r != 0 { | ||
let info = unsafe { info.assume_init() }; | ||
if !info.dli_sname.is_null() { | ||
let name = unsafe { CStr::from_ptr(info.dli_sname) }; | ||
if let Ok(name) = name.to_str() { | ||
rtprintpanic!("{depth}: {}\n", rustc_demangle::demangle(name)); | ||
return unwind::_URC_NO_REASON; | ||
} | ||
} | ||
} | ||
|
||
rtprintpanic!("{depth}: {ip:p}\n"); | ||
unwind::_URC_NO_REASON | ||
} | ||
|
||
let mut count = 0usize; | ||
unsafe { unwind::_Unwind_Backtrace(frame, ptr::from_mut(&mut count).cast()) }; | ||
if count > 128 { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Count will never be > 129 so the number of omitted frames is going to be incorrect anyways. It's going to be a huge number anyways since we are handling a stack overflow. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, it will be?! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh sorry I though the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, fair enough... I'll change it so it just prints that some frames were omitted. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Most of the time, yep, but I recently got a stack overflow from allocating a very large array in a single stack frame. A backtrace would have been handy there! |
||
rtprintpanic!( | ||
"[... omitted {} frame{} ...]\n", | ||
count - 128, | ||
if count - 128 > 1 { "s" } else { "" } | ||
); | ||
} | ||
} |
Uh oh!
There was an error while loading. Please reload this page.