访问长度为0的vector引起的低概率coredump问题的定位

         最近发布版本后， 发现了一个低概率的core dump告警,  其实， 在互联网千万甚至上亿的请求下， 再低概率的core都能被频繁触发， 所以也算不上低概率， 每隔几分钟就有core, 那就展开定位吧。

        首先基本可以肯定的是， core是由本次代码修改引起的。  先来做做前戏准备动作：

        1.  确保core文件是完成的， 没有被截断的

        2.  确保core文件没有被strip

        3.  确保core文件不丢失， 且与so对应

        4.  保存当时的log

        如上前戏都是老生常谈了 ， 我们在博客中多次提及。

         下面开始分析：

        5.  先用gdb分析core, 发现确实core在新增的业务代码中， 且有函数名称， 但遗憾的是没有指明具体的代码行。 此时， 我再次用file命令确认了一下， so库没有被strip脱掉衣服， 这算是万幸！ （这个有点奇怪， 通常来说， 没有被strip过， 且编译时候加了-g, 就会有代码行， 好吧， 先不纠结）

        6.  进入到函数中去review代码， 太浩瀚了， 没有发现明显可疑的地方。

        7.  再次用gdb的f命令、i locals、i args和i catch进行分析， 没有发现明显的异常。

        于是我想， 能不能抓到core对应的请求包？ 

       8. 于是开启全量抓包（要随时删除没core的包， 因为包太大， 会占用服务器空间）， 等待core的发生， 过了5分钟， 有core了， 然后分析core文件， 从core文件中找到对应了关键变量（比如qq号码）， 然后根据这个关键值来过滤上述抓到的包， 根据博文中之前讲过的方法， 很easy地过滤出了core对应的请求包， 貌似有点眉目了。

       9. 将这个包进行重放， 预期可能会core, 但实际并没有。  其实， 逻辑上来讲， 相同的请求不一定会再次触发core.

       10.  找到当时(core)的log进行分析， 找到当时的具体日志， 有log的地方肯定没有core, 于是只要朝log代码行的后面进行分析。 范围大大缩小了啊！

       11. 继续看代码， 可是代码中有很多分支， 当时具体进入了哪个分支呢？ 这个是可以确定的， 我们利用gdb的i args和i locals能找到当时每个形参变量和局部变量的值， 这样就知道当时代码是怎么走的。 就这样， 直接看代码走向， 最后锁定了位置。

        结果是： 在某低概率分支， 程序访问了一个长度概率为0的vector,  呵呵哒。

        修改代码， 对代码进行保护， 再次发布， 没有core了， 问题解决。

        其实， 回过头来看， 还是蛮简单的， 都是我们博文中之前介绍过的一些gdb分析core的方法。