每当我的程序崩溃的时候,我都会用核心转储 (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 却不会告诉我程序在哪里崩溃了: