__cxa_demangle 返回的指针需手动 free，因其内部用 malloc 分配内存，ABI 要求调用者释放；它不复用输入缓冲区，也无配套释放函数。
为什么 __cxa_demangle 返回的指针需要手动 free
因为 __cxa_demangle 内部用 malloc 分配了内存来存放解码后的字符串，C++ ABI 规范明确要求调用者负责释放——它不复用传入的缓冲区，也不提供配套的 free 封装函数。
常见错误是直接用 std::string 构造后就丢弃原始指针，导致内存泄漏：
char* demangled = __cxa_demangle(mangled_name, nullptr, nullptr, &status); std::string s(demangled); // ❌ 忘了 free(demangled)
正确做法是：
- 检查
status == 0再使用返回值 - 用
std::unique_ptr<char decltype></char>管理生命周期 - 或显式
free(demangled)，尤其在循环中反复调用时
__cxa_demangle 的第 2、3 个参数（output_buffer 和 length）怎么安全使用
这两个参数允许你提供预分配缓冲区，避免 malloc，但极易误用：
若 output_buffer 非空但 length 过小，函数会返回 nullptr，且不修改 length；只有当缓冲区确实不够时，它才通过 length 输出所需最小字节数（含终止符）。
安全写法是两步尝试：
立即学习“C++免费学习笔记（深入）”；
- 先传
nullptr+0获取所需长度 - 再
malloc对应大小（注意：必须 >= 返回值），重试解码 - 别忘了最终
free这块内存
示例关键逻辑：
size_t len = 0;
char* buf = __cxa_demangle(mangled, nullptr, &len, &status); // 第一次：获取长度
if (buf) { free(buf); buf = nullptr; } // 清理试探性分配
buf = static_cast<char*>(malloc(len));
if (buf) __cxa_demangle(mangled, buf, &len, &status); // 第二次：填入
不同编译器生成的 mangled 名是否都能被 __cxa_demangle 处理
不能。该函数只处理符合 Itanium C++ ABI 规范的 mangling 格式，也就是 GCC、Clang 默认使用的格式。
MSVC 使用完全不同的 mangling 方案（如 ?func@@YAXXZ），传给 __cxa_demangle 会直接返回 nullptr，status 设为 -2（invalid_args）或 -3（invalid_mangled_name）。
判断是否可用的依据只有 status == 0，而非返回值非空——某些非法输入也可能返回非空指针（ABI 实现细节差异）。实际工程中建议：
- 仅对已知来自 GCC/Clang 的符号（如
__cxa_throw栈帧、typeid(T).name()输出）调用 - 对 Windows PE 模块或 MSVC 编译的 DLL，改用
UnDecorateSymbolName（DbgHelp） - 跨平台日志工具中，需先检测编译器 ABI 类型，再分发解码逻辑
从 backtrace_symbols 获取的地址行里提取 mangled 名的坑
backtrace_symbols 返回的字符串形如 "./a.out(_Z12my_func_v2_i+0x15) [0x400a15]"，括号内是 mangled 名加偏移，但：
- 括号可能嵌套（如模板特化带函数指针参数），正则匹配容易截断
- 名称末尾可能有
@plt、@GLIBCXX_3.4等版本修饰符，__cxa_demangle能容忍，但部分旧版 libstdc++ 会失败 - 若符号被 strip 过，
backtrace_symbols可能只返回地址（"[0x400a15]"），此时无 mangled 名可解
稳妥做法是：用 strchr 找第一个 '('，再从右往左找匹配的 ')'，然后在中间子串里跳过开头的模块名和 '+' 偏移部分——不要依赖固定分隔符。
真正难处理的是动态链接库中符号重定向（如 libfoo.so(_Z12real_func_v2i@plt)），此时需先去掉 @plt 后缀再解码。
