迷途指標
在電腦編程領域中,迷途指標(英語:Dangling pointers),或稱懸空指標,跟野指標(Wild pointers),皆是一種不指向任何合法的對象的指標。在更一般化形式中,迷途參照(dangling references)與野參照(wild references)是指無法解析出合法所在的參照。
當所指向的對象被釋放或者收回,但是對該指標沒有作任何的修改,以至於該指標仍舊指向已經回收的主記憶體地址,此情況下該指標便稱迷途指標。若作業系統將這部分已經釋放的主記憶體重新分配給另外一個行程,而原來的程式重新參照現在的迷途指標,則將產生無法預料的後果。因為此時迷途指標所指向的主記憶體現在包含的已經完全是不同的數據。通常來說,若原來的程式繼續往迷途指標所指向的主記憶體地址寫入數據,這些和原來程式不相關的數據將被損壞,進而導致不可預料的程式錯誤。這種類型的程式錯誤,不容易找到問題的原因,通常會導致記憶體區段錯誤(Linux系統中)和一般保護錯誤(Windows系統中)。如果作業系統的主記憶體分配器將已經被覆蓋的數據區域再分配,就可能會影響系統的穩定性。
某些程式語言允許未初始化的指標的存在,而這類指標即為野指標。野指標所導致的錯誤和迷途指標非常相似,但野指標的問題更容易被發現。
迷途指標的成因
[編輯]在很多程式語言中(如C語言)從主記憶體中刪除一個對象或者返回時刪除堆疊幀後,並不會改變相關的指標的值。該指標仍然指向原來的主記憶體地址,即使參照已經刪除,現在也可能已經被其它行程使用了。
一個直接的例子,如下所示:
{
char *cp = NULL;
/* ... */
{
char c;
cp = &c;
} /* c falls out of scope */
/* cp is now a dangling pointer */
}
上述問題的解決方法是在該部分程式退出之前立即給CP賦0值(NULL)。另一個辦法是保證CP在沒有初始化之前,將不再被使用。
迷途指標經常出現在混雜使用malloc() 和 free() 庫呼叫: 當指標指向的主記憶體釋放了,這時該指標就是迷途的。和前面的例子一樣,一個避免這個錯誤的方法是在釋放它的參照後將該指標的值重設為NULL,如下所示:
#include <stdlib.h>
{
char *cp = malloc ( A_CONST );
/* ... */
free ( cp ); /* cp now becomes a dangling pointer */
cp = NULL; /* cp is no longer dangling */
/* ... */
}
有個常見的錯誤是當返回一個基於棧分配的局部變數的地址時,一旦呼叫的函數返回,分配給這些變數的空間將被回收,此時它們擁有的是"垃圾值"。
int * func ( void )
{
int num = 1234;
/* ... */
return #
}
在呼叫func之後一段時間,嘗試從該指標中讀取num的值,可能仍然能夠返回正確的值(1234),但是任何接下來的函數呼叫會覆蓋原來的棧為num分配的空間。這時,再從該指標讀取num的值就不正確了。如果要使一個指向num的指標都返回正確的num值,則需要將該變數聲明為static。
野指標的產生
[編輯]野指標指的是還沒有初始化的指標。嚴格地說,程式語言中每個指標在初始化前都是野指標。
一般於未初始化時便使用指標就會產生問題。大多數的編譯器都能檢測到這一問題並警告用戶。
int f(int i)
{
char* cp; //cp is a wild pointer
static char* scp; //scp is not a wild pointer: static variables are initialized to 0
//at start and retain their values from the last call afterwards.
//Using this feature may be considered bad style if not commented
}
迷途指標導致的安全漏洞
[編輯]如同緩衝區溢位錯誤,迷途指標/野指標這類錯誤經常會導致安全漏洞。 例如,如果一個指標用來呼叫一個虛擬函式,由於vtable指標被覆蓋了,因此可能會訪問一個不同的地址(指向被利用的代碼)。或者,如果該指標用來寫入主記憶體,其它的數據結構就有可能損壞了。一旦該指標成為迷途指標,即使這段主記憶體是唯讀的,仍然會導致資訊的泄露(如果感興趣的數據放在下一個數據結構裏面,恰好分配在這段主記憶體之中)或者訪問權限的增加(如果現在不可使用的主記憶體恰恰被用來安全檢測)。
避免迷途指標的錯誤
[編輯]避免迷途指標,有一種受歡迎的方法——即使用智能指標(Smart pointer)。智能指標使用參照計數來回收對象。一些其它的技術包括tombstone法和locks-and-keys法。
另外,可以使用 DieHard 主記憶體分配器[1],它虛擬消除了類似其它主記憶體錯誤(不合法或者兩次釋放主記憶體)的迷途指標錯誤。
還有一種辦法是貝姆垃圾收集器,一種保守的垃圾回收方法,能夠替代C和C++中標準主記憶體分配函數。這種方法完全消除了迷途指標的錯誤,通過去除主記憶體釋放的函數代之以垃圾回收器完成對象的回收。
像Java語言,迷途指標這樣的錯誤是不會發生的,因為Java中沒有明確地重新分配主記憶體的機制。而且垃圾回收器只會在對象的參照數為零時重新分配主記憶體。
迷途指標的檢測
[編輯]為了能發現迷途指標,一種普遍的編程技術——一旦指標指向的主記憶體空間被釋放,就立即把該指標置為空指標或者為一個非法的地址。當空指標被重新參照時,此時程式將會立即停止,這將避免數據損壞或者某些無法預料的後果。這將使接下來的編程過程產生的錯誤變得容易發現和解決了。這種技術在該指標有多個複製時就無法起到應有的作用了。
一些除錯器會自動地用特定的模式來覆蓋已經釋放的數據,如0xDEADBEEF
(Microsoft's Visual C/C++ 除錯器,例如,根據哪種類型被釋放採用 0xCC
,0xCD
或者 0xDD
[2])。這種方法通過將數據無用化,來防止已經釋放的數據重新被使用。這種方法的作用是非常顯著的(該模式可以幫助程式來區分哪些主記憶體是剛剛釋放的)。
值 | 名字 | 描述 |
---|---|---|
0xCD | Clean Memory | Allocated memory via malloc or new but never written by the application. |
0xDD | Dead Memory | Memory that has been released with delete or free. Used to detect writing through dangling pointers. |
0xFD | Fence Memory | Also known as "no mans land." This is used to wrap the allocated memory (surrounding it with a fence) and is used to detect indexing arrays out of bounds or other accesses (especially writes) past the end (or start) of an allocated block. |
0xCC | When the code is compiled with the /GZ option, uninitialized variables are automatically assigned to this value (at byte level). | |
0xAB | Memory allocated by LocalAlloc(). | |
0xBAADF00D | Bad Food | Memory allocated by LocalAlloc() with LMEM_FIXED,but not yet written to. |
0xFEEEFEEE | OS fill heap memory, which was marked for usage, but wasn't allocated by HeapAlloc() or LocalAlloc(). Or that memory just has been freed by HeapFree(). |
某些工具,如Valgrind, Mudflap[3] 或者 LLVM[4] 可以用來檢測迷途指標的使用。
相關條目
[編輯]外部連結
[編輯]- Pointers and Arrays (C99)
- Topics on Pointers and Arrays
- Dangling Pointer New Hacking Technique (Security)
- Dangling pointers[永久失效連結]
參考文獻
[編輯]- ^ E. Berger and B. Zorn, DieHard: Probabilistic Memory Safety for Unsafe Languages (頁面存檔備份,存於互聯網檔案館) (DieHard website (頁面存檔備份,存於互聯網檔案館))
- ^ Visual C++ 6.0 memory-fill patterns. [2009-09-21]. (原始內容存檔於2007-10-24).
- ^ Mudflap Pointer Debugging. [2009-09-21]. (原始內容存檔於2021-03-22).
- ^ Dhurjati, D. and Adve, V. Efficiently Detecting All Dangling Pointer Uses in Production Servers 互聯網檔案館的存檔,存檔日期2009-03-20.