转载自：点击打开链接http://blog.csdn.net/slvher/article/details/9144161
前段时间开发的一个后端C模块上线后，线上出core，初始时，由于访问压力不大，所以崩溃是上线3天左右出现的。当时用gdb跟进调用堆栈并检查源码，发现出core位置的代码没有啥问题。由于当时开发任务较重，且该模块不保存状态（崩溃重启不影响对外服务），所以没有深入跟进。后来随着客户端版本逐渐放量导致访问压力上升，噩梦开始了。。。
该模块会不定时core掉，而且几乎每次崩溃时的调用堆栈都不一样，关键是最后几层堆栈很多都位于几乎不可能出问题的代码中，比如库函数或厂里的公共库。
好在在众多core文件中发现规律：每次基本都是在对内存动态操作时挂掉，比如malloc/realloc/free/new/delete都引起了崩溃。而且幸运的是，崩溃进程还是输出了一些关键信息，比如下面这些（这些是在不同的崩溃时刻分别输出的）：
*** glibc detected *** malloc(): memory corruption: 0x0000002a95c1ff10 ***
*** glibc detected *** double free or corruption (out): 0x0000000000f0d910 ***
*** glibc detected *** free(): invalid next size (normal): 0x0000002a96103b00 ***
*** glibc detected *** free(): invalid next size (fast): 0x0000000000f349d0 ***
*** glibc detected *** corrupted double-linked list: 0x0000002a95f062e0 ***
从上面的日志也可以看到，每次引起崩溃的直接原因都可能不同。用gdb又仔细查看core文件发现，有时进程是收到SIGABRT信号后退出，有时又是收到SIGSEGV信号后退出。
由此，基本定位了崩溃原因：内存访问越界导致破坏了heap的数据结构。用valgrind在线下环境启动进程，试图重现崩溃或定位越界访问的代码，遗憾的是，脚本压了1个小时也没出现崩溃，而valgrind的输出报告也没有越界代码位置的提示。
最终，仔细检查源码后发现，在某个回调函数中，new出来的buffer接收完通过http post方式发送过来的2进制数据后，我又多写了1行代码，类似于：recv_buf[data_len] = '\0'，导致越界多写1个字节，最终引起各种莫名其妙的内存崩溃。
经验教训：
1）调用堆栈信息对定位问题帮助很大，但也不可尽信。比如这次遇到的情况，每次出core的调用堆栈几乎都不一样，而且最后几层栈帧都是不可能出现问题的库函数或久经考验的公司公共库，这种情况下，思维需要跳出局部，在更高的层次寻找规律或原因
2）一旦定位崩溃属于堆内存读写越界问题，就仔细检查自己的代码吧，因为库函数或公共库出问题的概率太小了，所以不要存在侥幸心理，这个时候，盲目的自信要不得
3）本来自认为对内存操作已经很小心了，没想到还是在想当然的瞬间写下犯错的代码，导致最终花费很多时间和精力去“捉虫”。不过好在跟进崩溃的过程中增加了一点分析/定位问题的经验，也算有些收获吧
=============== EOF =================