最近項(xiàng)目突然收到了一個(gè)緊急的問題報(bào)告 - 用戶在進(jìn)行某些關(guān)鍵操作的時(shí)候整個(gè)軟件突然就crash掉了。幸好產(chǎn)品繼承了自動(dòng)抓取dump的功能。。。

收到dump之后，通過windbg打開，查看相應(yīng)的callstack。迅速定位到出錯(cuò)的線程。在調(diào)用MapViewOfFile()的時(shí)候沒有map成功導(dǎo)致crash。 接下來，我們需要知道為什么為何map失敗？通過GetLastErrorCode()，我們得知進(jìn)程OutOfMemory導(dǎo)致map失敗。MapViewOfFile（）需要映射512KB（4Mb）連續(xù)內(nèi)存，而通過!address -summary命令，我們發(fā)現(xiàn)系統(tǒng)里最大的連續(xù)內(nèi)存塊為1.5Mb。Crash因此發(fā)生了。 至此，我們可以肯定，該crash是由于memory leak造成MapViewOfFile（）失敗。那么，是什么leak了？重新看上面的輸出信息，我們可以看到，MEM_MAPPED使用的內(nèi)存高達(dá)934Mb，MEM_PRIVATE使用的內(nèi)存為805Mb。據(jù)此，我們懷疑，產(chǎn)品里所使用的memory mapped file可能會(huì)存在大量的leak。 運(yùn)行命令!address -f:MEM_MAPPED，會(huì)得到類似的輸出： 第三列，也就是RgnSize，為當(dāng)前MMF的映射窗口大小。查看了該輸出，我們發(fā)現(xiàn)，窗口大小為512kB的文件在500個(gè)左右，而大小為256KB的文件多大1800個(gè)。據(jù)此，我們可以鎖定這些256KB的MMF文件。 下面的問題，就是，誰映射了這么多的MMF文件？在此不同的項(xiàng)目可以有不同的方法。如果你很熟悉項(xiàng)目數(shù)據(jù)的話，你可以先通過dd查看一下該256KB的內(nèi)容都是啥？有沒有你所熟悉的內(nèi)容？如果是字符串的話那就更容易定位問題的所在地方了。 這里，我們假設(shè)我們不熟悉文件的內(nèi)容，從而無法猜測這些數(shù)據(jù)是誰產(chǎn)生的。我們只能采取其他辦法。 上面輸出的第一列，也就是BaseAddr，為該map view的地址。如果我們要使用該map view的話，我們必須要有對(duì)應(yīng)的指針指向該view。因此，我們隨機(jī)選了一個(gè)256KB的view的baseaddress，然后通過下面的命令查找誰還指向了這塊內(nèi)存。 從該輸出我們能夠看到，大概有10多個(gè)地方保存有該指針地址。接下來，我們就需要查看誰，也就是那些類的instance還保存這些地址。此處沒有其他好的辦法，只能在這些地址四處通過dds命令來查看是否有對(duì)象的symbol。 在查看了多個(gè)地址之后，我們發(fā)現(xiàn)，有一個(gè)vftable為CMMFSerializer的對(duì)象。這給了我們極大的肯定：該類名里有MMF!十有八九是該類的leak！ 接下來，我們的目標(biāo)為誰創(chuàng)建了CMMFSerializer對(duì)象而沒有銷毀？首先，我們通過x命令來獲得CMMFSerializer的虛表地址，這樣我們就能夠在heap里搜索這些對(duì)象都存在哪里。 然后，運(yùn)行!heap命令，就能夠查看到擁有這些對(duì)象的地址了。 從我們的輸出能夠看到，大量的CommunicatorObj對(duì)象存在heap里。這就說明了CommunicatorObj這些對(duì)象沒有被刪除掉。從而，我們可以做這樣的結(jié)論：CommunicatorObj的泄漏導(dǎo)致了如此之多的MMF的泄漏，以及很高的MMF_PRIVATE使用率如此之高。剩下來的工作就很簡單了，看看代碼，分析分析哪些地方使用了CommunicatorObj。

轉(zhuǎn)載于:https://www.cnblogs.com/xiaxi/p/3719263.html

總結(jié)

以上是生活随笔為你收集整理的MemoryMappingFile泄漏分析过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。