使用gdb定位for循环中的段错误的一种方法

事情的经过是这样的，博主是在一个开源架构中做事，前段时间在敲一条命令的时候直接造成进程崩溃，并且稳定复现。虽然进程注册了相关的信号处理函数打印出了崩溃的线程调用栈，但是发现出问题的函数是在一个for循环中被循环调用了几千次，根本不知道是哪一次循环的时候出的问题，当然也可以通过加日志把循环次数等关键字打印出来，不过我不想修改代码重新出包。用gdb捣鼓了好一会儿终于想到了一个办法（本人几乎没怎么用过gdb，都是有需要直接上）。

代码大概是这样的：

struct opt{
  boost::variant<int, string, bool> val;
  string name;  // 表示val实际的变量类型
}
vector<opt> opv;  //这个vector事先是已经有2000个元素了

void func(opt o) {
  if (o.name == "int")
    cout << boost::get<int>(o.val) << endl;   // 原来的代码并不是cout，这里为了方便，主要是用 
                                          // boost::get
  else if (o.name == "string")
    cout << boost::get<string>(o.val) << endl;
  ……
}

for (auto &o : opv) {
  func(o);
}

调用栈明显指向函数"func"，并且通过命令的回显可以看到抛出了一个boost::get_bad异常，其实这个时候已经知道是boost::get指定的数据类型不匹配的问题，但是具体到是哪一个opt中的“name”和“val”类型不匹配呢。

利用gdb attach到我们运行的进程上去，并在函数func处打一个断点:

b func

然后忽略这个断点（不要删除断点）:

ignore 1

然后再次敲触发这个问题的命令，我们的进程会在收到SIGTERM信号的时候暂停，此时查看断点的命中次数：

i b 1

 此时我们可以看到断点1命中了譬如说是500次，那么我们就知道是vector中的第500个opt出现了期望的数据类型和实际保存的数据类型不一致的情况。由于这个vector在源码中指定了内容，因此我们就可以轻易找出来代码中是哪一个opt出的问题，最终发现的问题是这样的：

struct opt{
  boost::variant<int, string, bool> val;
  string name;  // 表示val实际的变量类型
}
opt f;
f.val = 0;
f.name = string;
cout << boost::get<string>(f.val) << endl;   // val存储的是int，按照string去get抛出异常

gdb小白让大佬们见效了。