plsql中报错argument out of range_我们是怎么发现C++异常从堆栈追踪中消失的原因的...

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