访问长度为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. 于是开启全量抓包（