問題描述

在最近的后臺服務中，新增將某個指令的請求數(shù)據(jù)落盤保存的功能。在具體實現(xiàn)時，采用成員變量來保存請求消息代理頭，在接收響應以及消息管理類釋放時進行銷毀。測試反饋，該服務偶發(fā)崩潰。

問題分析

測試環(huán)境上運行的是rel版程序，由于在編譯時去掉了調試信息（-g）以及開啟O3級別優(yōu)化，從崩潰dump的堆棧上，只看到程序崩潰的調用棧，函數(shù)入?yún)⒌缺粌?yōu)化掉，由于此處沒有打日志，只能想其他辦法來復現(xiàn)。猜測是重復釋放指針導致的崩潰，接下來繼續(xù)分析。

從rel版本的調用棧上看，只看見最后銷毀的函數(shù)調用，而在實際代碼中，有兩處銷毀的函數(shù)調用入口，為什么在dump中看到的調用棧順序與實際代碼不一致呢？猜測是開啟O3優(yōu)化，將函數(shù)內聯(lián)。

做了以下實驗來分析，

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來輸出堆棧信息分別如下：

結論：在Rel模式下，O3級別的優(yōu)化內聯(lián)了調用函數(shù)，如果從崩潰點往上回溯有多個可能入口點，那僅憑dump信息不能確認是哪個入口觸發(fā)的崩潰。

構造測試環(huán)境

通過分析代碼，得知要觸發(fā)可能的多重釋放，需要構造一邊創(chuàng)建，一邊銷毀的場景。

創(chuàng)建：可通過測試工具，定時高頻發(fā)送特定指令，觸發(fā)創(chuàng)建流程銷毀：可在定時任務中，進行無效狀態(tài)上報，觸發(fā)銷毀流程為了加快崩潰復現(xiàn)速度，創(chuàng)建以及銷毀的速度需要合理匹配，如果太快銷毀，會導致無法進入創(chuàng)建流程。經(jīng)過分析嘗試，最終設定測試工具每50毫秒發(fā)送一次，后臺服務每50ms上報無效狀態(tài)。

為進一步驗證崩潰的想法，在銷毀操作等關鍵路徑添加日志，啟動Rel版來重現(xiàn)。經(jīng)過長時間的測試，獲得了2次寶貴的崩潰dump以及對應的日志。每次dump要花費2個半小時甚至更多才能復現(xiàn)，說明這個問題是偶發(fā)問題，很可能與多線程競態(tài)有關。復現(xiàn)該問題的時間成本有點高，不過，從獲得的dump以及日志已足以定位問題。

日志分析

同一后臺服務，不同業(yè)務模塊的日志分布在不同日志文件中，在分析時，需要將各部分日志聚合起來，方便復現(xiàn)全流程。在聚合時，可以按需截取各模塊的最后若干行日志，每種日志中包含正常以及異常的日志，將其匯總到單一文件，然后結合代碼進行逐行關聯(lián)分析。

在分析過程中，遇到一些框架方面的疑問，通過詢問相關同事得到解答。目前的消息收發(fā)框架在接收消息時，先將消息放入線程池的消息隊列，通過信號量來喚醒線程，線程從消息隊列中獲取消息，從消息中取出處理函數(shù)進行處理。
在應用層處理不同消息時，可能處理同一個變量時，會有發(fā)生競態(tài)。通過對釋放指針的分析，正常釋放指針指都有一定的規(guī)律，當觸發(fā)崩潰時，釋放的指針值與正常的值有明顯區(qū)別。

經(jīng)驗小結 發(fā)現(xiàn)有dump文件時，查看dump文件生成時間，將當時的日志以及可執(zhí)行文件，連同dump文件一并放在獨立的文件夾中，便于后續(xù)分析。因為當前的日志文件以及可執(zhí)行文件可能被刪除以及更新。每一次問題的解決，都是一次對已有系統(tǒng)的再深入認識，理解。構造復現(xiàn)環(huán)境時，要使用Rel版本，且只能通過日志來確認程序流程，而不是斷點。在linux上，不能使用嵌套屬性的互斥鎖，它會破壞設計意圖，讓潛在的死鎖更加難以發(fā)現(xiàn)。讓錯誤盡早暴露好過后續(xù)找錯。大膽假設，小心求證，勝利的曙光終會出現(xiàn)。

到此這篇關于Linux上定位后臺服務偶發(fā)崩潰的解決方法的文章就介紹到這了,更多相關Linux上定位后臺服務崩潰問題內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！