最近，我們的軟件在運行過程中，遇到了一個很詭異的問題。

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

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

1、初步分析

我們在軟件中安裝了異常信息捕獲機制，但是軟件發(fā)生閃退時，并沒有捕獲到有效dump文件(崩潰信息存放在dump文件中)，生成的dump文件是空的!可能是在導(dǎo)出異常上下文信息時發(fā)生了二次崩潰，所以沒有生成有效的dump文件。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6、總結(jié)

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