C++的backtrace

开始之前

很多语言的log模块都有一个功能，就是在打log的时候能够追溯调用栈，有的时候对查bug能有点帮助。之前我也想过给我们的log模块加上C++的backtrace的功能，迟迟一直没有做主要是两个原因：一是C++的backtrace在各个平台和编译器上都不太一样，比较冗杂；二是C/C++在编译优化之后，调用行之类的信息和甚至一些函数可能就被优化没了。所以能提供的信息就相当有限。前两天刚好有朋友问有没有提供这个，所以就花了点时间整理了下适配方案。

思路和方案

具体到方案上，不同编译器、不同的平台都有自己的规则，但是也有少数的事实标准。所以还是可以笼统地分几个主流平台处理这个backtrace。我参考了一些gcc文档、boost代码和其他流传的一些库和方法，总结起来有几种方案。有些方法能提取去模块名称（函数在哪个动态库和或哪个二进制之类），但是有些不能。所以为了简化并且统一，我就没输出模块名。另外为了方便对比，我先贴一下测试的函数:

// 普通函数
void func1(int times) {
    if (times > 0) {
        func1(times - 1);
        return;
    }

    print_trace();
}

// 成员函数
class functor2 {
public:
    void func2(int times) {
        if (times & 0x01) {
            func2(times - 1);
        } else {
            func1(times - 1);
        }
    }
};

// 静态成员
class functor3 {
public:
    static void func3(int times) {
        if (times & 0x01) {
            func3(times - 1);
        } else {
            functor2 f;
            f.func2(times - 1);
        }
    }
};

// 操作符
struct functor4 {
    void operator()(int times) {
        if (times & 0x01) {
            (*this)(times - 1);
        } else {
            functor3::func3(times - 1);
        }
    }
};

// 本地函数
static void func5(int times) {
    if (times & 0x01) {
        func5(times - 1);
    } else {
        functor4 f;
        f(times - 1);
    }
}
// 还是普通函数
void func6(int times) {
    if (times & 0x01) {
        func6(times - 1);
    } else {
        func5(times - 1);
    }
}

Linux/Unix like环境

backtrace方案

libunwind

最简单的一种方式是使用libunwind。他已经给你封装好了接口，比较简单。基本流程就是unw_getcontext->unw_init_local->枚举每一帧unw_get_proc_name+unw_get_proc_info。简化一下代码大概这样:

execinfo.h和backtrace

第二种是使用gcc/clang自带的execinfo.h和backtrace功能。代码如下：

但是这种方法很多环境里并没有这个头文件和接口，比如MinGW和Android里都没有。所以好事得有fallback的候选方案。

unwind.h和_Unwind_Backtrace

第三种是用POSIX的 unwind.h: _Unwind_Backtrace。这个虽然MinGW里有，但是返回的数据是空的。NDK里也有，但是我没看是否可以用，ndk似乎提供了自己的backtrace函数，我没有去尝试，应该和这个差不多。

这种方法只能提取出函数地址，并不能解析符号。boost.stacktrace也是用了这种方法，它用_Unwind_Backtrace地区出符号以后用了addr2line去做符号转换，写法很暴力。所以我认为这是最后的fallback方案了。

使用_Unwind_Backtrace得先定义回调函数用以填充数据，然后调用_Unwind_Backtrace，代码如下:

上述方法理论上在Unix like的系统下都有效。不过我只测过macOS和Linux。

解析符号-demangle

gcc和clang或者libunwind直接解出的符号是原始的符号名称。当然很不好看，所幸的是gcc和clang都提供了内置函数abi::__cxa_demangle来把符号翻译成易懂的版本。这个接口连文档里都是只是提及了一下，我还是看头文件里的注释才知道怎么用的。差评。

前面也提到了boost.stacktrace的做法，它使用了_Unwind_Backtrace来解析函数地址，然后fork进程用addr2line来转换，然后等进程执行完后读取输出，而且还是每个地址fork一个进程跑addr2line。真是暴力又不靠谱，平白无故增加了个进程开销。

接下来可以看看执行结果。

Linux下使用libunwind

命令和输出:

Linux下使用backtrace

命令和输出:

Linux下使用unwind+addr2line

命令和输出:

Windows环境

backtrace方案

Windows上的MinGW64里没有execinfo.h的头文件，gcc和clang都没有，所以不能用上面提到的方法。unwind.h倒是有，但是我本地试了下并没有作用，会返回一个空的0帧。于是参考了下boost.stacktrace和MSDN里的做法，主要分两种

dbghelp

第一种是使用dbghelp库。先用CaptureStackBackTrace抓出执行栈的地址集合。然后使用SymFromAddr获取符号数据。

dbgeng+IDebugClient+IDebugControl+IDebugSymbols

第二种是使用dbgeng库和几个调试服务的组件IDebugClient/IDebugControl/IDebugSymbols。也是需要先用CaptureStackBackTrace抓出执行栈的地址集合。然后用IDebugClient来Attach到当前进程上，再用IDebugControl等待Attach完成，最后用IDebugSymbols导出符号数据。

boost.stacktrace就是用的第二种方法。这种方式比第一种那种更通用一些，因为导入了调试服务器，所以甚至可以使用远程调试文件。但是第二种方法再注册服务的时候有一大陀的magic number，我总觉得很不靠谱。而且需要等待Attach完成。这样的话怕是在突发性的大量使用的情况下（比如服务突然间短暂的异常，打印了茫茫多Error Log）会大幅降低性能。所以我感觉还是优先用第一种方式好一些。

不过无论哪种方法。MSVC下都必须开/Zi选项，因为这两个接口都依赖pdb文件。如果pdb文件不正确，输出的符号也会错误（函数地址是正确的），如果没有pdb文件，输出就会缺失符号信息。

以下是两种方式的编译命令和结果。

Windows+MSVC使用dbghelp

命令和输出:

Windows+MSVC使用dbgeng组件

命令和输出:

Windows+MinGW64+addr2line

前面也提到了MinGW下的gcc和clang是没有execinfo.h的，unwind.h里的东西输出也是空值。所以也只能和MSVC一样使用dbghelp或者dbgeng。但是由于gcc和clang会把符号表写在二进制里而不是pdb文件里。所以解析符号必然失败。所以我们在Windows下得gcc和clang提取调用栈得时候得跳过符号解析。所幸我们仍然可以用addr2line来解析地址。所以就有了以下结果。

命令和输出:

结束

以上所有测试代码和运行结果都放在 https://gist.github.com/owt5008137/78e1fea9a0221ddf9ed540f4adacf358 。

更完整的实现我已经放到了util代码的log模块中（log_stacktrace.h和[log_stacktrace.cpp][13]）。因为为了最小依赖，默认不会开libunwind的版本，默认windows下使用dbghelp。提取方法的检测可以写到cmake的检测脚本里，尽可能提供多的数据并且没有太高的额外开销(坚决不启动新进程，不block wait)。然后再log模块里增加了一个选项，可以控制一个范围内的错误级别，在打印原本得错误信息之后追加打印这个调用栈，这样看出错得关系得信息会更容易些。

另外utils的代码在Linux/Windows和macOS上测试过ok了。valgrind也跑过了没有问题。唯一的麻烦是不同平台的libunwind的以来库不太一样。我写了个cmake脚本会尝试去查找一下libunwind-和libunwind-generic，找不到的情况的话只手动加了。这也是默认不开libunwind的原因之一。

[13]: https://github.com/atframework/atframe_utils/blob/master/src/log/log_stacktrace.cpp

Previousatframework的etcd模块化重构Next2017

Last updated

Was this helpful?