前段时间开发的一个后端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 ***
该模块会不定时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 ***