昨晚快下班的时候， 同学X说自己的代码有core, 而且还是概率的， 不太好搞定, W哥对此很感兴趣， 于是就展开定位。 我觉得这是个好的学习机会， 于是就在旁观
1. 直接上阵， gdb分析core, 没发现比较直观的线索。
2. 怀疑是编译问题， 也就是我之前在博客专门讨论过的“协议core”问题， 但仅仅是怀疑。
3. review改动的代码， 没发现明显的可疑地方。
4. strace -p xxx , 然后发起请求触发core, 非常奇怪的是， 用strace的时候， 程序居然不core, 也算是奇葩了。 先忽略这个现象， 这不是根本问题。 要说明的是， strace通常是分析core的利器， 我们在博文中多次说过了。5. 看log, 将core的log和非core的log进行对比， 结果log非常多， 而且杂， 能分析一些线索， 但没有明显分析出core的地方。
于是W哥提出了一个很重要的思路： 找到预期有log但没有打出log的地方， 进行夹逼， 可是， 代码log较少, 于是提议补log. 今天早上， 同学X再次review自己写的代码发现了一处可疑的地方， 修改之， 就不core了。
其实， 如果实在是没有review出代码的问题， 那就多加log吧， 找到预期有log但没有log的地方， 这样就能知道core在哪里了。 好方法。
最后， 我对原来的代码进行简化和类比， 便于示例说明：
if(it != vec.end() || a == 100)
{
b = vec[0];
}聪明的你一定知道core的地方了， 最后这个code有助于我们以后review代码的core, 但定位core问题的思路更加重要。