轉 GFlags 使用詳解

轉載地址：https://blog.csdn.net/wl_fln/article/details/6283587

 

若是你是C++程序員，若是你寫過一個很複雜的程序，若是你常常碰到莫名其妙的崩潰問題。那麼你就有可能遭遇了野指針。若是你比較細心，注意了Debug Output輸出窗口的話，那麼你就有可能注意到這樣一行提示：
HEAP:   Free   Heap   block   xxxxxxxx modified   at   xxxxxxxx  after   it   was   freed

 

GFlags是Windows debug tools 工具包下的一個工具,在Windows 2000的Resource Kit中也能夠找獲得。用來設置一些調試屬性，整體上分爲3個級別System，Kernel和Image File。咱們設置好Path環境變量,將其指向Debug tools工具的目錄下。

下載安裝 gflags:

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

http://www.ithov.com/Soft/system/systest/38210.shtml

GFlags 

- 老牌的PageHeap配置工具，有命令行和GUI兩種操做方式，功能比較全，包含在Windbg調試器安裝包內。一樣在Windows 2000 Professional SP2 以上可用。

一些使用GFlags命令行的例子：

配置正常頁堆：

"C:/Program Files/Debugging Tools for Windows (x86)/gflags.exe" /p /enable qq.exe

配置徹底頁堆：

"C:/Program Files/Debugging Tools for Windows (x86)/gflags.exe" /p /enable qq.exe /full

列出當前啓動了頁堆的進程列表：

"C:/Program Files/Debugging Tools for Windows (x86)/gflags.exe" /p

取消頁堆設置：

"C:/Program Files/Debugging Tools for Windows (x86)/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時：