問(wèn)題描述
在最近的后臺(tái)服務(wù)中，新增將某個(gè)指令的請(qǐng)求數(shù)據(jù)落盤(pán)保存的功能。在具體實(shí)現(xiàn)時(shí)，采用成員變量來(lái)保存請(qǐng)求消息代理頭，在接收響應(yīng)以及消息管理類(lèi)釋放時(shí)進(jìn)行銷(xiāo)毀。測(cè)試反饋，該服務(wù)偶發(fā)崩潰。
問(wèn)題分析
測(cè)試環(huán)境上運(yùn)行的是rel版程序，由于在編譯時(shí)去掉了調(diào)試信息（-g）以及開(kāi)啟O3級(jí)別優(yōu)化，從崩潰dump的堆棧上，只看到程序崩潰的調(diào)用棧，函數(shù)入?yún)⒌缺粌?yōu)化掉，由于此處沒(méi)有打日志，只能想其他辦法來(lái)復(fù)現(xiàn)。猜測(cè)是重復(fù)釋放指針導(dǎo)致的崩潰，接下來(lái)繼續(xù)分析。
從rel版本的調(diào)用棧上看，只看見(jiàn)最后銷(xiāo)毀的函數(shù)調(diào)用，而在實(shí)際代碼中，有兩處銷(xiāo)毀的函數(shù)調(diào)用入口，為什么在dump中看到的調(diào)用棧順序與實(shí)際代碼不一致呢？猜測(cè)是開(kāi)啟O3優(yōu)化，將函數(shù)內(nèi)聯(lián)。
做了以下實(shí)驗(yàn)來(lái)分析，
void test_dump()
{
int* p = NULL;
*p = 2; // occur dump
}
void test_f2(int b)
{
b += 1;
test_dump();
}
void test_f1(int a)
{
a+=1;
test_f2(a);
}
int main()
{
test_f1(1);
return 0;
}
在Debug以及Rel模式下，觸發(fā)崩潰，使用gdb來(lái)輸出堆棧信息分別如下：
結(jié)論：在Rel模式下，O3級(jí)別的優(yōu)化內(nèi)聯(lián)了調(diào)用函數(shù)，如果從崩潰點(diǎn)往上回溯有多個(gè)可能入口點(diǎn)，那僅憑dump信息不能確認(rèn)是哪個(gè)入口觸發(fā)的崩潰。
構(gòu)造測(cè)試環(huán)境
通過(guò)分析代碼，得知要觸發(fā)可能的多重釋放，需要構(gòu)造一邊創(chuàng)建，一邊銷(xiāo)毀的場(chǎng)景。
創(chuàng)建：可通過(guò)測(cè)試工具，定時(shí)高頻發(fā)送特定指令，觸發(fā)創(chuàng)建流程銷(xiāo)毀：可在定時(shí)任務(wù)中，進(jìn)行無(wú)效狀態(tài)上報(bào)，觸發(fā)銷(xiāo)毀流程為了加快崩潰復(fù)現(xiàn)速度，創(chuàng)建以及銷(xiāo)毀的速度需要合理匹配，如果太快銷(xiāo)毀，會(huì)導(dǎo)致無(wú)法進(jìn)入創(chuàng)建流程。經(jīng)過(guò)分析嘗試，最終設(shè)定測(cè)試工具每50毫秒發(fā)送一次，后臺(tái)服務(wù)每50ms上報(bào)無(wú)效狀態(tài)。
為進(jìn)一步驗(yàn)證崩潰的想法，在銷(xiāo)毀操作等關(guān)鍵路徑添加日志，啟動(dòng)Rel版來(lái)重現(xiàn)。經(jīng)過(guò)長(zhǎng)時(shí)間的測(cè)試，獲得了2次寶貴的崩潰dump以及對(duì)應(yīng)的日志。每次dump要花費(fèi)2個(gè)半小時(shí)甚至更多才能復(fù)現(xiàn)，說(shuō)明這個(gè)問(wèn)題是偶發(fā)問(wèn)題，很可能與多線程競(jìng)態(tài)有關(guān)。復(fù)現(xiàn)該問(wèn)題的時(shí)間成本有點(diǎn)高，不過(guò)，從獲得的dump以及日志已足以定位問(wèn)題。
日志分析
同一后臺(tái)服務(wù)，不同業(yè)務(wù)模塊的日志分布在不同日志文件中，在分析時(shí)，需要將各部分日志聚合起來(lái)，方便復(fù)現(xiàn)全流程。在聚合時(shí)，可以按需截取各模塊的最后若干行日志，每種日志中包含正常以及異常的日志，將其匯總到單一文件，然后結(jié)合代碼進(jìn)行逐行關(guān)聯(lián)分析。
在分析過(guò)程中，遇到一些框架方面的疑問(wèn)，通過(guò)詢(xún)問(wèn)相關(guān)同事得到解答。目前的消息收發(fā)框架在接收消息時(shí)，先將消息放入線程池的消息隊(duì)列，通過(guò)信號(hào)量來(lái)喚醒線程，線程從消息隊(duì)列中獲取消息，從消息中取出處理函數(shù)進(jìn)行處理。
在應(yīng)用層處理不同消息時(shí)，可能處理同一個(gè)變量時(shí)，會(huì)有發(fā)生競(jìng)態(tài)。通過(guò)對(duì)釋放指針的分析，正常釋放指針指都有一定的規(guī)律，當(dāng)觸發(fā)崩潰時(shí)，釋放的指針值與正常的值有明顯區(qū)別。
經(jīng)驗(yàn)小結(jié) 發(fā)現(xiàn)有dump文件時(shí)，查看dump文件生成時(shí)間，將當(dāng)時(shí)的日志以及可執(zhí)行文件，連同dump文件一并放在獨(dú)立的文件夾中，便于后續(xù)分析。因?yàn)楫?dāng)前的日志文件以及可執(zhí)行文件可能被刪除以及更新。每一次問(wèn)題的解決，都是一次對(duì)已有系統(tǒng)的再深入認(rèn)識(shí)，理解。構(gòu)造復(fù)現(xiàn)環(huán)境時(shí)，要使用Rel版本，且只能通過(guò)日志來(lái)確認(rèn)程序流程，而不是斷點(diǎn)。在linux上，不能使用嵌套屬性的互斥鎖，它會(huì)破壞設(shè)計(jì)意圖，讓潛在的死鎖更加難以發(fā)現(xiàn)。讓錯(cuò)誤盡早暴露好過(guò)后續(xù)找錯(cuò)。大膽假設(shè)，小心求證，勝利的曙光終會(huì)出現(xiàn)。
到此這篇關(guān)于Linux上定位后臺(tái)服務(wù)偶發(fā)崩潰的解決方法的文章就介紹到這了,更多相關(guān)Linux上定位后臺(tái)服務(wù)崩潰問(wèn)題內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
