不可直接用；std::stacktrace不支持多线程崩溃时安全采集，因其构造非async-signal-safe，易致二次崩溃，应改用backtrace+backtrace_symbols_fd配合线程专属日志与事后符号化解析。
std::stacktrace 在多线程崩溃时是否可用？
不可直接用。std::stacktrace 是 C++23 引入的轻量级堆栈快照工具，但它**不捕获当前线程的完整调用上下文**，更不支持在信号处理（如 SIGSEGV）中安全调用——它内部可能触发内存分配或调用 dladdr 等非异步信号安全函数，导致二次崩溃。
崩溃时获取线程本地堆栈的正确姿势
必须绕过 std::stacktrace，改用异步信号安全的堆栈采集方式。核心是：在 signal 处理器中调用 backtrace + backtrace_symbols_fd，且仅对触发信号的线程生效。
- 注册信号处理器前，用
sigprocmask阻塞所有线程的崩溃信号，再用pthread_sigmask在目标线程解阻塞，确保只有出问题的线程响应 -
backtrace返回的void*数组必须用backtrace_symbols_fd（而非backtrace_symbols）写入文件描述符，避免 malloc - 每个线程需维护独立的崩溃日志 fd（例如
open("/tmp/stack-<pid>-<tid>.log", O_WRONLY|O_CREAT, 0644)</tid></pid>），不能共用stderr - C++23 的
std::stacktrace::current()只能在正常执行路径中调用，比如在线程入口函数开头打点，或配合std::terminate_handler（但后者无法区分线程）
为什么不能在 signal handler 里构造 std::stacktrace？
因为 std::stacktrace 构造函数会调用 __cxa_demangle 和动态符号解析，这些都不是异步信号安全的。实测在 SIGABRT handler 中调用 std::stacktrace::current() 后，约 30% 概率卡死或 segfault。
典型错误现象：malloc(): unaligned fastbin chunk detected 或 double free or corruption (!prev) —— 这是信号中断了 malloc 内部状态所致。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
可验证的最小反例：
void crash_handler(int) {
// ❌ 危险！此行极大概率导致进程彻底挂死
auto st = std::stacktrace::current(); // 触发非 async-signal-safe 调用
write(STDERR_FILENO, "crash\n", 6);
_exit(1);
}
实际部署建议：线程 ID + 符号化后处理
运行时只记录原始地址，符号解析留到事后。这样既保证信号 handler 安全，又保留调试能力。
- 信号 handler 中调用
backtrace(buf, 128)，将结果写入线程专属临时文件（路径含syscall(SYS_gettid)） - 程序退出前，主控线程汇总所有
/tmp/stack-*.log，用addr2line -e ./myapp -f -C -p批量还原符号 - 若需实时符号化，改用
libdw（elfutils）的dwfl_addrmodule接口，它支持在非信号上下文安全解析 - 注意：启用
-g编译且不 strip，否则addr2line无法映射源码行
真正棘手的是线程局部存储（TLS）变量访问——崩溃时若正在修改 TLS，backtrace 可能读到损坏的栈帧。这种情况下，唯一可靠的方式是依赖 core dump 配合 gdb -c core -ex "thread apply all bt"。
