stl map find使用不当导致的低概率core dump问题的定位

       最近呢， 收到低概率core dump告警， 不频繁， 但挺恼人， 那就展开定位呗。再低概率的core, 在亿万请求下， 必然会发生。

       这么搞起：

       1. 上外网core dump的机器一看， 没有core文件了， 于是从backup目录找到了备份的core

       2. 看了一下core文件的大小， 太小， 无法定位， 这肯定是被截断了。

       3. 完全放开机器的core开关， 并重启服务， 蹲点等待core dump的发生(考虑到性能问题， 不建议在默认情况下打开core开关).  

       4. 第二天， 有core了， 从backup文件中找到了core, 看了一下大小， 符合预期， 高兴啊。

       5. 准备用gdb挂起分析， 我靠， 该模块机器居然没有安装gdb

       6. 那行， 把外网机器的so和core拷贝到安装gdb的对应测试机器上进行分析， 结果不靠谱。 拷贝core需要的时间不短呢， 我当时用了tar

       7. 那就手动在外网机器上安装gdb, 这是我第一次安装gdb， 不难， linux上一切皆文件， 直接拷贝测试机上对应的gdb文件即可(可以用whereis命令查找位置)，不像Windows上那样有恶心的注册表

       8. 安装后， 用gdb挂起core分析， 定位到了对应的代码行， 果然有嫌疑。 然后， 修改发版本解决了。

       

      后来我找运维同学批量安装了gdb, 棒棒哒！

       特别注意：

       1. 这么珍贵的core文件， 一定一定要做好备份， 我当时用tar命令的时候， 敲错了命令， 破坏了core文件， 幸亏， 我备份了。 否则就恶心到自己了

       2. 平时要重视代码review， 某哥之前review出了类似代码问题

       

       当时导致低概率core dump的类似代码为：

#include <iostream>#include <string>#include <map>using namespace std;int main(){map<string, string> m;m["1"] = "2";map<string, string>::iterator it = m.find("1");cout << it->second << endl;    return 0;  }

       上面没有对it进行判断， 就直接用了second,  为core dump的出现埋下了伏笔。 

       具体调试很简单的， 我就不说了， 之前的博客已经有详细介绍。