最近，我們的軟件在運(yùn)行過程中，遇到了一個(gè)很詭異的問題。

軟件在一個(gè)測(cè)試同事的win7 32位系統(tǒng)上運(yùn)行1個(gè)多小時(shí)后會(huì)閃退崩潰。奇怪的是，在測(cè)試該產(chǎn)品的主要測(cè)試人員的win10電腦上，則從未出現(xiàn)過這個(gè)情況。

下面詳細(xì)介紹一下這個(gè)問題的排查過程，以及給我們的一些啟示!

1、初步分析

我們?cè)谲浖邪惭b了異常信息捕獲機(jī)制，但是軟件發(fā)生閃退時(shí)，并沒有捕獲到有效dump文件(崩潰信息存放在dump文件中)，生成的dump文件是空的!可能是在導(dǎo)出異常上下文信息時(shí)發(fā)生了二次崩潰，所以沒有生成有效的dump文件。

這個(gè)問題在他電腦上出現(xiàn)過好幾次了。于是，讓同事將windows系統(tǒng)上常用的軟件調(diào)試?yán)鱳indbg掛載到目標(biāo)進(jìn)程上，看看復(fù)現(xiàn)閃退時(shí)能否抓到有效的信息。結(jié)果問題復(fù)現(xiàn)后，抓到的異常上下文對(duì)應(yīng)的代碼模塊基本是不可能產(chǎn)生異常的，所以問題排查還是沒有頭緒!

突然無意中想到，軟件是運(yùn)行一兩個(gè)小時(shí)后出現(xiàn)的，難道是軟件中有內(nèi)存泄漏?把進(jìn)程的虛擬內(nèi)存耗完了，導(dǎo)致再申請(qǐng)內(nèi)存時(shí)都失敗了，產(chǎn)生了空指針，導(dǎo)致空指針訪問違例，導(dǎo)致軟件閃退。這種假設(shè)可以解釋windbg捕獲到的不可能發(fā)生異常的代碼塊的現(xiàn)象了!

于是重新啟動(dòng)軟件，觀察了任務(wù)管理器中我們軟件對(duì)應(yīng)的進(jìn)程的內(nèi)存占用情況?？吹轿覀冘浖倪M(jìn)程的內(nèi)存一直在增長，在運(yùn)行1個(gè)多小時(shí)后竟然漲到1GB多了，這下基本可以確定，肯定是內(nèi)存泄漏導(dǎo)致的內(nèi)存被耗完，從而導(dǎo)致軟件再申請(qǐng)內(nèi)存失敗了，導(dǎo)致訪問了空指針，導(dǎo)致軟件閃退了!

下面就是使用一些內(nèi)存泄漏的檢測(cè)工具來來定位內(nèi)存泄漏的模塊了!

2、使用騰訊的tMemMonitor內(nèi)存泄漏檢測(cè)工具檢測(cè)內(nèi)存泄露

最開始嘗試使用騰訊的tMemMonitor內(nèi)存泄漏檢測(cè)工具，檢測(cè)一下內(nèi)存泄漏發(fā)生在哪個(gè)模塊中。

具體的做法是，使用tMemMonitor將我們的軟件啟動(dòng)起來：

讓軟件運(yùn)行一個(gè)多小時(shí)，讓軟件產(chǎn)生1GB以上的內(nèi)存泄漏，然后關(guān)閉軟件，如果檢測(cè)到內(nèi)存泄漏就會(huì)彈出生成檢測(cè)報(bào)告的提示，打開報(bào)告就可以看到檢測(cè)結(jié)果了。

注意，tMemMonitor內(nèi)存泄漏檢測(cè)工具只能檢測(cè)release版本的程序，被檢測(cè)程序必須由tMemMonitor啟動(dòng)，并且被監(jiān)測(cè)程序在退出時(shí)必須是正常退出的。如果關(guān)閉軟件時(shí)發(fā)生了崩潰，tMemMonitor是不會(huì)生成內(nèi)存泄漏報(bào)告的。

檢測(cè)報(bào)告中會(huì)顯示發(fā)生內(nèi)存泄漏的dll或exe的模塊名，并且會(huì)將相關(guān)的函數(shù)調(diào)用堆棧打印出來，比如：

但實(shí)際跑下來，看到檢測(cè)報(bào)告，并沒有看到有用的信息，檢測(cè)到泄漏內(nèi)存的都比較小，和實(shí)際泄漏的內(nèi)存大小相差甚遠(yuǎn)!難道不是用戶態(tài)的內(nèi)存泄漏?是內(nèi)核態(tài)的內(nèi)存泄漏?

3、使用windbg檢測(cè)內(nèi)存泄漏

使用tMemMonitor工具分析不出來，于是又嘗試使用windbg分析了一把。使用此方法之前，要預(yù)先安裝好windbg工具。最新版本的windbg是從內(nèi)置在微軟官方的SDK中的，可以自行到微軟的官方網(wǎng)站上下載安裝。

此內(nèi)存泄漏檢測(cè)方法，會(huì)用到windbg安裝路徑下的gflags.exe和umdh.exe程序，如下所示：

具體的操作步驟是：

1)打開cmd窗口，切換到windbg的安裝目錄中，比如我的安裝路徑是：C:\Program Files\Windows Kits\10\Debuggers\\x86。

2)先使用命令設(shè)置用戶態(tài)函數(shù)棧回溯標(biāo)記：gflags /i xxxxxxxxx.exe +ust，具體含義可以以“gflags /?”查看gflags相關(guān)命令行的參數(shù)說明：

3)使用umdh.exe將時(shí)刻1時(shí)的堆內(nèi)存分配情況輸出到日志文件中：umdh.exe -pn:xxxxxxxxx.exe -f:E:\log1.txt。其中，umdh.exe是windows debug tools 下的一款命令行工具，它的全程是User Mode Dump Heap 這個(gè)工具會(huì)分析當(dāng)前進(jìn)程在堆上分配的內(nèi)存?？梢允褂?ldquo;umdh /?”查看umdh.exe支持的命令行參數(shù)，以及如何使用的：

然后讓程序運(yùn)行一個(gè)多小時(shí)后，讓程序有足夠多的內(nèi)存泄漏，然后再用命令：umdh.exe -pn:xxxxxxxxx.exe -f:E:\log2.txt，導(dǎo)出時(shí)刻2時(shí)的堆內(nèi)存分配使用情況。

4)使用命令：umdh.exe E:\log1.txt E:\log2.txt -f:E:\result.txt，比較兩個(gè)時(shí)刻中間的時(shí)間段的堆內(nèi)存的增長及使用情況，找出可能出現(xiàn)內(nèi)存泄漏的地方：

這似乎還是有問題，明明泄漏了1GB多的內(nèi)存，怎么檢測(cè)結(jié)果中最多泄漏的那項(xiàng)計(jì)算出來泄漏的內(nèi)存才200MB，相差的比較多的，看來windbg似乎也不可信啊!

4、使用代碼分塊注釋的辦法，定位到發(fā)生內(nèi)存泄漏的模塊

問題還是沒查出來，這個(gè)就比較頭疼了，軟件馬上要對(duì)外發(fā)布正式商用版本了，這個(gè)問題必須要解決啊!

最后沒辦法，只能采用逐步注釋代碼的方法，看看能否定位內(nèi)存泄漏發(fā)生在哪個(gè)模塊中。經(jīng)多次嘗試發(fā)現(xiàn)，與dcs數(shù)據(jù)協(xié)作模塊的庫有關(guān)系。然后查看了一下dcs服務(wù)器的連接狀態(tài)，服務(wù)器連不上，底層一直在不斷的定時(shí)重連，難道是每次重連失敗后沒有釋放socket套接字等資源導(dǎo)致的內(nèi)存泄漏?

于是找到相關(guān)模塊的負(fù)責(zé)同事，讓他們排查，排查下來后發(fā)現(xiàn)，確實(shí)是服務(wù)器重連失敗后沒有將相關(guān)資源釋放掉導(dǎo)致的內(nèi)存泄漏(使用websocket和服務(wù)器通信的)!

后來在我自己的兩臺(tái)電腦上驗(yàn)證了一下，軟件運(yùn)行在我win7 32位電腦上是有內(nèi)存泄漏的，但在我另一臺(tái)win7 64位系統(tǒng)上則沒有內(nèi)存泄漏。在測(cè)試同事的win10系統(tǒng)上，也詳細(xì)觀察了，win10系統(tǒng)上居然沒有內(nèi)存泄漏，軟件運(yùn)行一切正常!這個(gè)內(nèi)存泄漏難道是和操作系統(tǒng)是強(qiáng)相關(guān)的?

5、進(jìn)一步研究確認(rèn)

知道大概的原因之后，我又用windbg和tMemMonitor都重新檢測(cè)了一下內(nèi)存泄漏，看看哪個(gè)工具更好用，定位的更準(zhǔn)確!

我們選擇檢測(cè)的時(shí)間段內(nèi)，軟件已經(jīng)占用了1.15GB的內(nèi)存，內(nèi)存泄漏估計(jì)得有900MB左右了。

此時(shí)windbg分析出來的內(nèi)存泄漏模塊確實(shí)是對(duì)的，如下所示：

但是泄漏的內(nèi)存只有200MB左右，這和實(shí)際的內(nèi)存泄漏大小有很大的出入。當(dāng)前windbg分析出的內(nèi)存泄漏是用戶態(tài)的，可能有部分泄漏發(fā)生在程序的內(nèi)核態(tài)?

而騰訊的tMemMonitor和windbg比要遜色不少，tMemMonitor不僅檢測(cè)出的泄漏內(nèi)存大小比實(shí)際泄漏大小要小很多，而且根本沒有定位到發(fā)生內(nèi)存泄漏的模塊。所以，windbg還是要強(qiáng)大不少的。

經(jīng)后來驗(yàn)證，在另一臺(tái)的win7 64位系統(tǒng)中，之前之所以沒有內(nèi)存泄露，是因?yàn)檫@臺(tái)機(jī)器上登錄平臺(tái)的賬號(hào)是沒有dcs服務(wù)的權(quán)限，就不會(huì)登錄dcs服務(wù)器，就不會(huì)觸發(fā)dcs服務(wù)器的重連。而本例中的內(nèi)存泄漏就是dcs重連失敗后沒有清理相關(guān)資源導(dǎo)致的。后來使用一個(gè)有dcs服務(wù)權(quán)限的賬號(hào)在這臺(tái)win7 64位系統(tǒng)中登錄我們的軟件，同樣也出現(xiàn)了內(nèi)存泄漏。

但同樣的代碼、同樣的軟件在win10系統(tǒng)中卻沒有內(nèi)存泄漏，通過打印日志可以確定win10系統(tǒng)中也觸發(fā)了dcs服務(wù)器的重連了，這可能是win10系統(tǒng)的內(nèi)存管理機(jī)制和win7不同引起的吧!

6、總結(jié)

遇到問題后，要進(jìn)行深入細(xì)致的研究，要搞清楚各種情況的來龍去脈!在詳細(xì)的研究過程中要多思考多驗(yàn)證，會(huì)有新的發(fā)現(xiàn)和新的收獲!