menu
文章16
标签0
分类4
© 2024 落寒陌墨的Blog Powered by Typecho & Nexmoe

苏ICP备2021046226号-1

我们是怎么发现C++异常从堆栈追踪中消失的原因的

2022年7月30日 1567 汉字 436 围观 0 评论 程序人生

每当我的程序崩溃的时候，我都会用核心转储 (core dump) 文件来找出来崩溃发生的具体位置。（关于怎么产生和使用核心转储可以看我的文章。）一直以来我调程序的时候都是很开心的……直到我遇到了这个新的 bug。当我把它的核心转储文件载入到 GDB 之后，我很失望地发现所有的堆栈追踪 (stack trace) 都是关于系统库的，没有一行是关于我的代码的。

太长不看：那就看看这个补丁就好了。

让我们踏上探索未知的旅程吧。

背景介绍

为了帮助我亲爱的读者朋友们理解我日常的调程序过程，让我们来看看这个简短的 C++ 代码：

// compile with:
//   g++ -g -std=c++11 sigsegv.cc -o sigsegv -pthread
#include <thread>
#include <vector>
#include <iostream>

void foo() {
    std::vector<int> v;
    std::cout << v[100] << std::endl;
}

int main() {
    std::thread t(foo);
    t.join();
}

不出意外，这里应该要有一个段错误 (segmentation fault)。想要知道哪里触发了段错误，如果这个问题不是很容易触发的话，你可以把核心转储文件载入到 GDB 里面，或者如果这个问题很容易重现的话，你也可以直接在 GDB 里面重新跑一遍。那这里就让我们直接在 GDB 里面跑一遍：

    $ gdb ./sigsegv
    GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
    Reading symbols from ./sigsegv...done.
    (gdb) r
    Starting program: /tmp/sigsegv
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    [New Thread 0x7ffff6f4e700 (LWP 68189)]
    
    Thread 2 "sigsegv" received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0x7ffff6f4e700 (LWP 68189)]
    0x0000000000400f5d in foo () at sigsegv.cc:8
    8        std::cout << v[100] << std::endl;
    
    (gdb) bt
    #0  0x0000000000400f5d in foo () at sigsegv.cc:8
    #1  0x00000000004027dd in std::_Bind_simple<void (*())()>::_M_invoke<>(std::_Index_tuple<>) (this=0x617c48)
        at /usr/include/c++/5/functional:1531
    #2  0x0000000000402736 in std::_Bind_simple<void (*())()>::operator()() (this=0x617c48)
        at /usr/include/c++/5/functional:1520
    #3  0x00000000004026c6 in std::thread::_Impl<std::_Bind_simple<void (*())()> >::_M_run() (this=0x617c30)
        at /usr/include/c++/5/thread:115
    #4  0x00007ffff7b0dc80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #5  0x00007ffff76296ba in start_thread (arg=0x7ffff6f4e700) at pthread_create.c:333
    #6  0x00007ffff735f41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

可以看到，GDB 一如既往能够显示出来是在我们代码中的哪一行崩溃的。

到目前为止一切正常。但是在这一次的 bug 里面，我的代码用了 vector::at 来访问数组元素。如果访问越界，它会抛出 std::out_of_range 异常。

    // compile with:
    //   g++ -g -std=c++11 exception.cc -o exception -pthread
    #include <thread>
    #include <vector>
    #include <iostream>
    
    void foo() {
        std::vector<int> v;
        std::cout << v.at(100) << std::endl;
    }
    
    int main() {
        std::thread t(foo);
        t.join();
    }

看起来使用 at 是一个比 operator[] 更安全的写法。然而，这一次 GDB 却不会告诉我程序在哪里崩溃了：

$ gdb ./exception
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Reading symbols from ./exception...done.
(gdb) r
Starting program: /tmp/exception
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6f4e700 (LWP 68143)]
terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 100) >= this->size() (which is 0)

Thread 2 "exception" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff6f4e700 (LWP 68143)]
0x00007ffff728d428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

(gdb) bt
#0  0x00007ffff728d428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff728f02a in __GI_abort () at abort.c:89
#2  0x00007ffff7ae484d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff7ae26b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff7ae2701 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff7b0dd38 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff76296ba in start_thread (arg=0x7ffff6f4e700) at pthread_create.c:333
#7  0x00007ffff735f41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

乍一看一切正常，我的程序在临死之前告诉我 vector 抛出了 std::out_of_range 异常。我简直被我的程序感动了。但是我想知道具体是那哪里抛出了异常。

让我们看看这个堆栈追踪，里面竟然没有一行是我的代码。虽然说在这个例子里面，直接看一眼代码你就可以看出来问题出现在哪里了，但是在我真正的项目里面有1万行 C++ 代码，我真的需要 GDB 来告诉我具体是在哪一行出了问题。

现在你应该明白为什么我对这个事情这么执着了。

系统库里面有 Bug？

坐在我边上的哥们 Niel 告诉我这有可能是因为底层的库里面有 bug。

说实话，我一般来说不相信编译器、操作系统或者底层库会出现大到足以影响到我日常使用的 bug。我觉得这几乎是不可能发生的事情，因为这些都是广泛使用的基础设施。

但是 Niel 说他以前有遇到过底层库的 bug，而且他说他愿意帮我看一下这个问题，而且他人又超级好的，所以我们就一起开始看这个问题了。

恢复 ?? 符号

盯着 GDB 里面的 ?? 符号看是不会有任何帮助的。所以我决定把这些符号的名字找出来。我自以为我对 Ubuntu 已经有了足够的了解，所以我很自然地就打出来了 sudo apt install libstdc++-gdb。然而这个包并不存在。我花了点时间才找到了这个包正确的名字叫做 libstdc++6-5-dbg，其中6对应了 libstdc++.so.6，5指的是 GCC 5.4，因为我用的是 Ubuntu 16.04。

在安装好了调试符号之后，GDB 就给了我们更多的线索：

$ gdb ./exception
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Reading symbols from ./exception...done.
(gdb) r
Starting program: /tmp/exception
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6f4e700 (LWP 68314)]
terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 100) >= this->size() (which is 0)

Thread 2 "exception" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff6f4e700 (LWP 68314)]
0x00007ffff728d428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

(gdb) bt
#0  0x00007ffff728d428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff728f02a in __GI_abort () at abort.c:89
#2  0x00007ffff7ae484d in __gnu_cxx::__verbose_terminate_handler ()
    at ../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x00007ffff7ae26b6 in __cxxabiv1::__terminate (handler=<optimized out>)
    at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x00007ffff7ae2701 in std::terminate () at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x00007ffff7b0dd38 in std::execute_native_thread_routine (__p=<optimized out>)
    at ../../../../../src/libstdc++-v3/src/c++11/thread.cc:92
#6  0x00007ffff76296ba in start_thread (arg=0x7ffff6f4e700) at pthread_create.c:333
#7  0x00007ffff735f41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Glibc

我们决定跟着堆栈追踪从底向上地一层一层看过去。clone() 听起来并不十分有趣，所以我们就跳过了它。所以我们现在要看的是 pthread_create.c:333。一番搜索之后，我意识到了它是在 glibc 里面的。但是我用的是哪个版本的 glibc 呢？我的想法是用 ldd 先把 .so 文件找出来：

$ ldd ./exception
    linux-vdso.so.1 =>  (0x00007ffc77f54000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f23ae730000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f23ae51a000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f23ae150000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f23ade47000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f23aeab2000)

现在我们知道 .so 文件在哪里了，那具体是哪个版本呢？

$ ls -la /lib/x86_64-linux-gnu/libc.so.6
lrwxrwxrwx 1 root root 12 Mar  4 18:36 /lib/x86_64-linux-gnu/libc.so.6 -> libc-2.23.so

好了，现在我们就可以在 glibc 2.23 的源代码里面看一眼 pthread_create.c:333：

THREAD_SETMEM (pd, result, CALL_THREAD_FCT (pd));  // pthread_create.c:333

现在我想知道 CALL_THREAD_FCT 是做什么的，这看起来像是一个宏，我得找到这个宏的定义：

$ grep '#define CALL_THREAD_FCT' -r glibc-2.23
glibc-2.23/sysdeps/i386/nptl/tls.h:#define CALL_THREAD_FCT(descr) \

很幸运的是，这个符号真的是用 #define CALL_THREAD_FCT 定义出来的，但不幸的是我找到的结果跟我的机器并不是一个架构。但又非常幸运的是，我成功地猜到了我想要的在 glibc-2.23/sysdeps/x86_64/nptl/tls.h：

# define CALL_THREAD_FCT(descr) \
  ({ void *__res;                                                             \
     asm volatile ("movq %%fs:%P2, %%rdi\n\t"                                 \
                   "callq *%%fs:%P1"                                          \
                   : "=a" (__res)                                             \
                   : "i" (offsetof (struct pthread, start_routine)),          \
                     "i" (offsetof (struct pthread, arg))                     \
                   : "di", "si", "cx", "dx", "r8", "r9", "r10", "r11",        \
                     "memory", "cc");                                         \
     __res; })

我不太懂汇编，这看起来像是在调用 start_routine 并把 args 作为参数传进去。看起来也不是很有趣。

我们决定看一下下一层调用堆栈。

libstdc++

所以说我们需要找到 libstdc++ 的源代码。我意识到 libstdc++ 其实是 GCC 的一部分，所以说我们需要的是 GCC 5.4 的源代码。让我们看一看 ../../../../../src/libstdc++-v3/src/c++11/thread.cc:92：

extern "C"
{
  static void*
  execute_native_thread_routine(void* __p)
  {
    thread::_Impl_base* __t = static_cast<thread::_Impl_base*>(__p);
    thread::__shared_base_type __local;
    __local.swap(__t->_M_this_ptr);

    __try
      {
        __t->_M_run();
      }
    __catch(const __cxxabiv1::__forced_unwind&)
      {
        __throw_exception_again;
      }
    __catch(...)
      {
        std::terminate();  // line 92
      }

    return nullptr;
  }
} // extern "C"

当我打开这个文件的时候，我已经惊呆了。为什么 libstdc++ 想要捕获所有的异常？！就不能直接让用户程序崩溃吗！

这段代码说明了一切。我的代码肯定是跑在 try 代码块里面的。当它抛出一个异常之后，它会被92行的 catch 代码块捕获。但是到了程序的控制流已经被 catch 代码块捕获了的时候，所有的堆栈都已经被展开了 (stack unwind)，所有能帮助我调试程序的信息都被扔掉了。

Bug 报告

对我来说这看起来可以被称作 libstdc++ 的 bug。我搜索了一下，然后发现有人在2013年就报告了这个 Bug #55917，但是这个问题直到 GCC 8 才被修复。而且补丁本身非常简单，就是把 try-catch 删掉，直接让用户代码崩溃。

升级到 GCC 8

既然我们知道了这个问题已经在 GCC 8 里面修好了，我们就可以重新把程序用 GCC 8 编译一遍。因为 Ubuntu 16.04 的软件源里面没有包含 GCC 8，所以我们得用 ubuntu-toolchain-r/test PPA:

sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install g++-8

现在让我们重新编译一下之前的代码然后放到 GDB 里面试试：

$ g++-8 -g -std=c++11 exception.cc -o exception -pthread
$ gdb ./exception
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Reading symbols from ./exception...done.
(gdb) r
Starting program: /tmp/exception
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6f42700 (LWP 69463)]
terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 100) >= this->size() (which is 0)

Thread 2 "exception" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff6f42700 (LWP 69463)]
0x00007ffff7281428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

(gdb) bt
#0  0x00007ffff7281428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff728302a in __GI_abort () at abort.c:89
#2  0x00007ffff7ad78f7 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff7adda46 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff7adda81 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff7addcb4 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff7ad97f5 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x0000000000401274 in std::vector<int, std::allocator<int> >::_M_range_check (this=0x7ffff6f41e00, __n=100)
    at /usr/include/c++/8/bits/stl_vector.h:960
#8  0x0000000000401033 in std::vector<int, std::allocator<int> >::at (this=0x7ffff6f41e00, __n=100)
    at /usr/include/c++/8/bits/stl_vector.h:981
#9  0x0000000000400dd7 in foo () at exception.cc:8
#10 0x00000000004013a7 in std::__invoke_impl<void, void (*)()>(std::__invoke_other, void (*&&)()) (
    __f=<unknown type in /tmp/exception, CU 0x0, DIE 0x6a01>) at /usr/include/c++/8/bits/invoke.h:60
#11 0x0000000000401093 in std::__invoke<void (*)()>(void (*&&)()) (__fn=<unknown type in /tmp/exception, CU 0x0, DIE 0x6e68>)
    at /usr/include/c++/8/bits/invoke.h:95
#12 0x00000000004019da in std::thread::_Invoker<std::tuple<void (*)()> >::_M_invoke<0ul> (this=0x615c28)
    at /usr/include/c++/8/thread:234
#13 0x000000000040199b in std::thread::_Invoker<std::tuple<void (*)()> >::operator() (this=0x615c28)
    at /usr/include/c++/8/thread:243
#14 0x0000000000401970 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)()> > >::_M_run (this=0x615c20)
    at /usr/include/c++/8/thread:186
#15 0x00007ffff7b0857f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#16 0x00007ffff761d6ba in start_thread (arg=0x7ffff6f42700) at pthread_create.c:333
#17 0x00007ffff735341d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

注意看堆栈9，里面就是我们的代码！问题解决了！

经验教训

尽管底层的软件和库自身的问题影响到一般的程序的可能性很低，但它确实发生了，而且未来还有可能继续发生。所以说，不要害怕去深入底层看一看。

最后再次感谢 Niel 老哥。要不是有他帮我，我肯定不会深挖这个问题的。

0 评论

'