最近項目出現一個內存問題,跑的時間一久就提示堆被破壞了。使用CRTDBG工具只能檢測到大致的位置,無法具體到哪一行出現了問題了。而且我使用了智能指針,找內存越界就更困難了。
百度時發現了WINDWO下還有一個gflags工具,這個工具可以在踩內存的時時候就彈出警報,在VS下可能馬上定位到哪一行出現了問題,神器啊~。下面的轉的使用原理和方法,記錄方便以後查找
原貼:http://blog.csdn.net/wl_fln/article/details/6283587
GFlags
- 老牌的PageHeap配置工具,有命令行和GUI兩種操作方式,功能比較全,包含在Windbg調試器安裝包內。同樣在Windows 2000 Professional SP2 以上可用。
一些使用GFlags命令行的例子:
配置正常頁堆:
gflags /p /enable qq.exe
配置完全頁堆:
gflags.exe /p /enable qq.exe /full
列出當前啓動了頁堆的進程列表:
gflags.exe /p
取消頁堆設置:
gflags.exe /p /disable qq.exe
一些特殊選項解釋:
/unaligned
這個選項只能用於完全頁堆。當我們從普通堆管理器分配一塊內存時,內存總是8字節對齊的,頁堆默認情況下也會使用這個對齊規則,但是這會導致分配的內存塊的結尾不能跟頁邊界精確對齊,可能存在0-7個字節的間隙,顯然,對位於間隙範圍內的訪問是不會被立即發現。更準確的說,讀操作將永遠不能被發現,寫操作則要等到內存塊釋放時校驗間隙空間內的填充信息時才發現。/unaligned用於修正這個缺陷,它指定頁堆管理器不必遵守8字節對齊規則,保證內存塊尾部精確對齊頁邊界。
需要注意的是,一些程序啓用這個選項可能出現異常,例如IE和QQ就不支持。
/backwards
這個選項只能用於完全頁堆。這個選項使得分配的內存塊頭部與頁邊界對齊(而不是尾部與邊界對齊),通過這個選項來檢查頭部的訪問越界。
/debug
指定一啓動進程即Attach到調試器,對於那些不能自動生成dump的程序,是比較有用的選項。
完全頁堆:
當分配一塊內存時,通過調整內存塊的分配位置,使其結尾恰好與系統分頁邊界對齊,然後在邊界處再多分配一個不可訪問的頁作爲保護區域。這樣,一旦出現內存讀/寫越界時,進程就會Crash,從而幫助及時檢查內存越界。
因爲每次分配的內存都要以這種形式佈局,尤其對於小片的內存分配,即使分配一個字節,也要分配一個內存頁,和一個保留的虛擬內存頁(注意在目前的實現中,這個用作邊界保護區域的頁從來不會被提交)。這就需要大量的內存,到底一個進程需要多少內存,很難估算,因此在使用Page Heap前,至少保證你的機器至少設置了1G虛擬內存以上。
正常頁堆
正常頁堆原理與CRT調試內存分配函數類似,通過分配少量的填充信息,在釋放內存塊時檢查填充區域。來檢測內存是否被損壞,此方法的優點是極大的減少了內存耗用量。缺點是只能在釋放塊時檢測,不太好跟蹤出錯的代碼位置。
頁堆能處理的錯誤類型:
錯誤類型 | 正常頁堆 | 整頁堆 |
堆句柄無效 | 立即發現 | 立即發現 |
堆內存塊指針無效 | 立即發現 | 立即發現 |
多線程訪問堆不同步 | 立即發現 | 立即發現 |
假設重新分配返回相同地址(realloc) | 90%內存釋放後發現 | 90%立即發現 |
內存塊重複釋放 | 90%立即發現90% | 立即發現 |
訪問已釋放的內存塊 | 90%在實際釋放後發現 | 90%立即發現 |
訪問塊結尾之後的內容 | 在釋放後發現 | 立即發現 |
訪問塊開始之前的內容 | 在釋放後發現 | 立即發現 |
以下是舉例:
前期工作: 將gflags(默認安裝在C:/Program Files/Debugging Tools for Windows (x86))加入到path
案例1:
int _tmain(int argc, _TCHAR* argv[])
{
char *p = new char[8];
p[8] = 10;
delete[] p;
return 0;
}
程序本身是有問題的。數組已經越界,但是debug模式下並不報錯,release模式下也很大可能是不crash的。
在命令提示符下運行:
>gflags /p /enable test.exe /full
在release模式運行test.exe。exception將直接定位到 p[8] = 10; 這一行
案例2:
int _tmain(int argc, _TCHAR* argv[])
{
char *p = new char[9];
p[9] = 10;
delete[] p;
return 0;
}
以上代碼和案例1僅有一點不同,就是數組大小。但是如果運行
gflags /p /enable test.exe /full
在release模式下並不會出現exception並定位到 p[9] = 10;
原因是沒有設置 /unaligned 參數,具體看說明。案例2中,數組有9字節大小,按內存8字節對齊的說法,這塊內存應該是
16字節,後面還有7字節的空間,所以 p[9] = 10; 並不會產生exception。設置 /unaligned 參數,禁止8字節對齊,就
可以跟蹤到 p[9] = 10; 這個exception
>gflags /p /enable test.exe /full /unaligned
案例3:
class A
{
public:
int a;
void del(){
delete this;
a = 10;
}
};
int _tmain(int argc, _TCHAR* argv[])
{
A* a = new A();
a->del();
return 0;
}
在debug模式下可能產生exception:
HEAP: Free Heap block xxxxxxxx modified at xxxxxxxx after it was freed
在release模式下運行並不報錯,但是程序本身是有問題的,delete this; 之後,又給成員變量 a=10;
這顯然是不對的。
>gflags /p /enable test.exe /full
此時在debug下運行程序,會產生exception,並定位到 a = 10;
//----------------------------------------------------------------------------------------------------------------
1. 安裝:Debugging Tools for Windows (x86) ;
2. 開啓gflags: gflags -p /enable ***.exe /full。 “***.exe”爲需要調試的進程名,不需要絕對路徑。
3. 啓動要調試的程序,當執行異常操作後,VS這才變聰明瞭,直接指定到了直接導致異常的代碼處。頓時,晴空萬里。
啓動了gflags,調試運行就慢了,比較它要變聰明要學習足夠的東西。It's the same to ourselves.
不使用gflags時:
gflags -p /disable ***.exe