[[143029]]

在WWDC 2015上，除了Swift 2.0外，還有一個令人激動的消息：可以直接在Xcode 7上使用Clang的地址消毒劑（Address Sanitizer）了。這篇文章中我們將詳細討論下這個功能，比如它是怎樣工作的，以及使用的方法。這是Konstantin Gonikman提議的話題。

C語言中一種異常危險的情況

從很多方面來看，C語言都是一種偉大的編程語言。事實上，發明至今已逾40年，它仍然保持著強勁的勢頭。這足以說明它的偉大。這不是我學的第一門（也不是第二門）編程語言，但正是它，使我第一次真正揭開了計算機運行機制的神秘面紗。而且，它是我至今仍在使用的唯一語言。

然而，C也是一門非常危險的編程語言，代碼世界中的許多痛苦由它而生。它造成了許多怪異的bug，這些bug其他的編程語言根本無法表述。

內存安全是一個主要的問題。C語言中根本沒有內存安全可言。像下面的代碼，會被正常的編譯，而且可能正常運行：

char *ptr = malloc(5); 
ptr[12] = 0; 

這段代碼只申請了5字節的數組空間，卻通過指針寫入數據到第13字節上。在這個地址上，隱藏的數據損壞可能發生，也可能平安無事（比如在Apple平臺上，malloc函數總是最少分配16個字節，即使你申請少于16字節的空間，因此這段代碼在Apple平臺上運行正常，但不要依賴系統的這個特性）。這段錯誤代碼可能危害不大，也可能后患無窮。

更“聰明”的語言跟蹤數組的大小，在操作的時候會驗證下標的有效性。同樣的Java代碼，會比較可靠地拋出異常。有了異常機制，調試這些“神奇”問題就容易的多了。例如，一個變量應該為4，但實際上它的值為5，我們就知道某段修改該變量值的代碼出了問題（這樣至少我們會集中注意力到程序調試上，而不會盯著編譯器，因為它一般不會出錯）。但是使用C語言，我們根本無法做出假設，bug有可能是某段代碼“故意”修改變量值造成的，也可能是某段代碼使用了“壞指針”無意中修改了變量值。

整個產業已經開始著手解決這個問題。例如，Clang的靜態代碼分析，可以從代碼中查找特定類型的內存安全問題。如Valgrind之類的程序可以在運行時檢測到不安全的內存訪問。

Address Sanitizer是另外一種解決方案。它使用了一種新的方法，有利有弊。但仍不失為一個查找代碼問題的有力工具。

內存訪問驗證

許多這類工具在運行時驗證內存訪問的有效性，從而查找到問題。理論依據是：訪問內存時，通過比較訪問的內存和程序實際分配的內存，驗證內存訪問的有效性，從而在bug發生時就檢測到它們，而不會等到副作用產生時才有所察覺。

理想情況下，每個指針都會包含數據大小和指向內存的位置信息，因此可針對這些驗證每次的內存訪問。為何C編譯器在設計之初沒有加入驗證的特性，還沒有具體的原因。但附加在指針上的元數據會使程序無法兼容標準C編譯器編譯的代碼。這就意味著無法簡單使用系統庫，必然嚴重限制了使用該體系檢測代碼。

Valgrind解決以上問題的方案是：在模擬器上運行整個程序。這樣，就可以直接運行標準C編譯器生成的二進制文件，而不需要做任何額外的修改。然后在程序運行的時候進行分析，檢查程序處理的每一塊內存。這樣的方式可以使它高效運行所有程序，包括系統的庫，而不做任何修改。這樣做的代價是速度變得很慢，因此在一些效率要求高的程序中不實用。另外，這種方式需要深度了解某個平臺系統調用的含義，

只有這樣才能合適地追蹤內存改變狀態。因而必然需要針對特定宿主系統的深度整合。多年間，Valgrind對Mac的支持無明確計劃。截止本文發布之時，它還不支持Mac 10.10。

保護性內存分配得益于CPU內置的內存檢查工具。它取代了標準的malloc函數。使用時，每個分配內存結尾的后面會被標記為不可讀寫。當程序嘗試訪問后面的內存，會出錯。這樣的做法有一個弊端：硬件的內存保護精確度不夠。內存只能在內存頁尺度上被標記為可讀或不可讀，而在現代操作系統中，內存頁至少有4kB空間。這意味著每次內存分配至少都需要占用8kB內存：一頁內存用來存儲數據，另外一頁用來限制越界的內存訪問。即使只申請幾字節的內存，也需要這樣做。另外，這樣的做法也導致小規模的越界不會被檢測到。為了儲存針對標準malloc的內存的保護，需要分配內存到16字節的范圍內，因此，若分配的內存大小不是16字節的整數倍，余出的幾個字節將不受保護。

內存消毒劑機制嘗試在更小的粒度上處理內存受限。在本質上，這樣的內存分配保護機制較慢，但卻更實用。

追蹤受限內存

既然不能使用硬件層面的內存保護，就必須使用軟件的手段來實現。因為通過指針無法傳遞額外數據，跟蹤內存必須通過某種“全局表”來完成。這個表需要能被快速的讀取和修改。

內存消毒劑使用了一種簡單但是很巧妙的方法：它在進程的內存空間上保存了一個固定的區域，叫做“影子內存區”。用內存消毒劑的術語來說，一個被標記為受限的內存被稱作“中毒”內存。“影子內存區”會記錄哪些內存字節是中毒的。通過一個簡單的公式，可以將進程中的內存空間映射到“影子內存區”中，即：每8字節的正常內存塊映射到一個字節的影子內存上。在影子內存上，會跟蹤這8字節的“中毒狀態”。

每8字節的內存映射8位（1字節）的影子內存，我們自然會想到，每字節內存的“中毒狀態”只能通過影子內存上的一位來標記的。然而實際情況是，內存消毒劑在跟蹤內存狀態時，每字節使用一個整型值來記錄。它假定所有“中毒內存”塊都是連續的，且順序從后往前，因此可以使用影子內存的一個字節來表示正常內存塊中“中毒”的內存數量。例如：0表示所有內存都是正常的；1表示最后一個字節有問題；2表示最后兩個字節有問題，依次類推，7表示這幾個字節都有問題。若所有8字節都“中毒”，這個值就為負。使用這樣的方式，就可以在訪問內存的時候進行檢查。分配內存的起始位置一般來說不會太過接近，因此，假定“中毒”內存是連續的且從后往前的, 這樣不會帶來什么問題。

有了這個表結構，地址消毒劑在程序中生成額外的代碼來檢查每次使用指針的讀寫操作，并在內存中毒的狀態下拋出錯誤。該特性被集成在編譯器中，而不僅僅在外部庫和運行環境中存在，這樣帶來了不少好處：每個指針訪問可被可靠地標識，并將合適的內存檢查添加到機器碼中。

編譯器集成還支持一些簡潔的技巧, 比如，除了堆（heap）上分配的內存外，可以跟蹤保護本地和全局變量。本地和全局內存分配時會產生一些間隔，這些間隔內存若“中毒”可能導致溢出。這一點上，保護式內存分配無能為力，Valgrind也疲于應對。

編譯器集成的特性也有其缺點。詳細來說，地址消毒劑無法捕捉系統庫中的錯誤內存訪問。當然，它和系統庫是“兼容”的。當使用系統庫的時候，你可以打開內存消毒劑功能。比如，你可以構建一個鏈接Cocoa的程序，正常運行它。但是它不會捕捉Cocoa造成的錯誤內存訪問，也無法檢測你的代碼調用Cocoa時分配的內存。

內存消毒劑也能用來捕捉“釋放后使用”的錯誤。內存在釋放后都會被標記為“中毒”，之后無法對其再進行訪問。“釋放后使用”的錯誤在內存重用時危害不淺，因為那樣你會破壞不相關的數據。內存消毒劑會將剛釋放的內存放置到一個回收隊列中，在一段時間內將無法申請到這些內存，從而在重用時避免這樣的錯誤。自然，為每個指針訪問添加檢查代價不小。它取決于代碼做了什么，因為不同類型的代碼訪問指針內容的頻率各不相同。平均算來，內存檢查會降低大概2~5倍的速度，這個開銷挺大，但還不至于讓程序無法使用。

如何使用？

在Xcode 7上使用Address Sanitizer很簡單。當通過命令行編譯時，需要給clang命令調用添加-fsanitize=address參數。下面是一個測試程序：

編譯，通過Address Sanitizer運行：

程序立馬crash，輸出很多內容：

這里包含很多信息，真實場景中，這些信息將對跟蹤問題產生巨大幫助。它不僅顯示了錯誤內存寫入的位置，還標識了內存初始分配的位置。另外，還有其他附加信息。

在Xcode中使用內存消毒劑更簡單：編輯scheme，點擊Diagnostics標簽頁，選中"Enable Address Sanitizer"選項。然后就可以正常構建、運行，然后就能查看到大量診斷信息。

附加特性：不明確行為消毒劑

錯誤的內存訪問只是C語言中諸多“有趣”的不明確行為的一種。Clang還提供了其他的消毒劑，使用它可以捕捉許多不明確行為。以下是實例程序：

#include     #include     int main(int argc, char **argv) { 
 
        int value = 1; 
 
        for(int x = 0; x < atoi(argv[1]); x++) { 
 
            value *= 10; 
 
            printf("%d\n", value); 
 
        } 
 
    } 

運行代碼：

結果的最后有些怪異。毫無疑問，有符號整形值溢出是C語言中的不明確行為。若能將這個錯誤捕捉，而不是產生錯誤的數據，就再好不過了。不明確行為消毒劑能有所幫助，傳遞-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error參數來開啟它：

這里并不像地址消毒劑那樣輸出額外的信息，但是，在出現錯誤的時候，程序立即停止了執行，而且我們通過調試工具可以很簡單地查找問題。
不明確行為消毒劑暫時未集成到Xcode中，但是你可以在工程的build settings中添加compiler flags來使用。

結論

Address Sanitizer是一個偉大的技術，可以幫助我們查找到很多C代碼中的問題。它并不完美，不能查找到所有錯誤，但仍能提供非常有用的診斷信息。在這里，我強烈建議你在自己的代碼中嘗試使用它，你會發現令你吃驚的結果。