前段時間開發(fā)的一個后端C模塊上線后,，線上出core，初始時,，因?yàn)樵L問壓力不大,，所以崩潰是上線3天左右出現(xiàn)的。當(dāng)時用gdb跟進(jìn)調(diào)用堆棧并檢查源代碼,，發(fā)現(xiàn)出core位置的代碼沒有啥問題,。因?yàn)楫?dāng)時開發(fā)任務(wù)較重，且該模塊不保存狀態(tài)（崩潰重新啟動不影響對外服務(wù)）,，所以沒有深入跟進(jìn),。后來隨著client版本號逐漸放量導(dǎo)致訪問壓力上升,，噩夢開始了。,。,。
該模塊會不定時core掉，并且差點(diǎn)兒每次崩潰時的調(diào)用堆棧都不一樣,，關(guān)鍵是最后幾層堆棧非常多都位于差點(diǎn)兒不可能出問題的代碼中,，比方庫函數(shù)或廠里的公共庫。
好在在眾多core文件里發(fā)現(xiàn)規(guī)律：每次基本都是在對內(nèi)存動態(tài)操作時掛掉,，比方malloc/realloc/free/new/delete都引起了崩潰,。并且幸運(yùn)的是，崩潰進(jìn)程還是輸出了一些關(guān)鍵信息,，比方以下這些（這些是在不同的崩潰時刻分別輸出的）：
*** 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又細(xì)致查看core文件發(fā)現(xiàn),，有時進(jìn)程是收到SIGABRT信號后退出，有時又是收到SIGSEGV信號后退出,。
由此,，基本定位了崩潰原因：內(nèi)存訪問越界導(dǎo)致破壞了heap的數(shù)據(jù)結(jié)構(gòu)。用valgrind在線下環(huán)境啟動進(jìn)程,，試圖重現(xiàn)崩潰或定位越界訪問的代碼,，遺憾的是，腳本壓了1個小時也沒出現(xiàn)崩潰,，而valgrind的輸出報(bào)告也沒有越界代碼位置的提示,。
終于，細(xì)致檢查源代碼后發(fā)現(xiàn),，在某個回調(diào)函數(shù)中,，new出來的buffer接收完通過http post方式發(fā)送過來的2進(jìn)制數(shù)據(jù)后，我又多寫了1行代碼,，相似于：recv_buf[data_len] = '\0',，導(dǎo)致越界多寫1個字節(jié)，終于引起各種莫名其妙的內(nèi)存崩潰,。
經(jīng)驗(yàn)教訓(xùn)：
1）調(diào)用堆棧信息對定位問題幫助非常大,，但也不可盡信。比方這次遇到的情況,，每次出core的調(diào)用堆棧差點(diǎn)兒都不一樣,，并且最后幾層棧幀都是不可能出現(xiàn)故障的庫函數(shù)或久經(jīng)考驗(yàn)的公司公共庫，這樣的情況下,，思維須要跳出局部,，在更高的層次尋找規(guī)律或原因
2）一旦定位崩潰屬于堆內(nèi)存讀寫越界問題,，就細(xì)致檢查自己的代碼吧，因?yàn)閹旌瘮?shù)或公共庫出問題的概率太小了,，所以不要存在僥幸心理,，這個時候，盲目的自信要不得
3）本來自覺得對內(nèi)存操作已經(jīng)非常小心了,，沒想到還是在想當(dāng)然的瞬間寫下犯錯的代碼,，導(dǎo)致終于花費(fèi)非常多時間和精力去“捉蟲”。只是好在跟進(jìn)崩潰的過程中添加了一點(diǎn)分析/定位問題的經(jīng)驗(yàn),，也算有些收獲吧

=============== EOF =================