事情的经过是这样的,博主是在一个开源架构中做事,前段时间在敲一条命令的时候直接造成进程崩溃,并且稳定复现。虽然进程注册了相关的信号处理函数打印出了崩溃的线程调用栈,但是发现出问题的函数是在一个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小白让大佬们见效了。