C++23 std::stacktrace 怎么在程序崩溃时无痛捕获堆栈轨迹-C++-PHP中文网

std::stacktrace::current() 在崩溃时不可用，因其不满足 async-signal-safe 要求，且依赖完好栈帧；仅适用于正常执行时的日志打点、性能采样等主动场景。

c++23 std::stacktrace 怎么在程序崩溃时无痛捕获堆栈轨迹

不能无痛捕获——std::stacktrace::current() 在崩溃时根本不可用，强行调用大概率导致二次崩溃或静默失败。

为什么信号处理函数里调用 `std::stacktrace::current()` 是危险操作

POSIX 明确要求信号处理器内只能调用 async-signal-safe 函数，而 std::stacktrace::current() 内部会触发 dladdr、__cxa_demangle 和可能的堆内存分配，三者全都不满足该约束。实测在 SIGSEGV handler 中调用后，约 30% 概率出现 malloc(): unaligned fastbin chunk detected 或直接卡死。

它不检查当前栈帧是否完好——崩溃时栈已损坏，std::stacktrace::current() 可能返回空对象或抛 std::runtime_error
它不注册任何信号处理器，也不接管 std::terminate，完全不参与崩溃流程
即使成功返回，也只反映信号 handler 自身的单层调用栈（如 sig_handler），而非真正出问题的 foo → bar → segfault

哪些场景下 `std::stacktrace::current()` 确实能安全使用

它只适合在程序“正常运行中”主动打点，比如日志埋点、性能采样或异常传播链中手动记录上下文。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

在线程入口函数开头调用，确认线程启动路径：std::cerr

配合 std::set_terminate 捕获未处理异常（此时栈帧完整）：

void terminate_handler() {<br>  try { throw; }<br>  catch (const std::exception& e) {<br>    std::cerr     std::cerr   }<br>}

编译必须带 -g，链接需 -lbacktrace（GCC）或确保 Clang 启用了 libunwind，否则 to_string() 只输出地址

崩溃时真正可落地的替代方案

必须绕过 C++ 标准库，直连操作系统级 API，并严格遵守异步信号安全边界。

Linux 下：用 sigaction 注册 handler，在其中仅调用 backtrace + backtrace_symbols_fd，写入线程专属文件（路径含 syscall(SYS_gettid)）
Windows 下：用 SetUnhandledExceptionFilter + StackWalk64，注意加载 dbghelp.dll 并初始化符号引擎
所有平台都应避免在 signal handler 中做符号解析——只存原始地址，事后用 addr2line -e ./myapp 或 llvm-symbolizer 批量还原
若用多线程，每个线程需独立 open() 日志 fd，绝不能共用 stderr 或全局 FILE*