[[143029]]

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

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

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

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

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

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

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

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

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

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

內(nèi)存訪問驗證

許多這類工具在運行時驗證內(nèi)存訪問的有效性，從而查找到問題。理論依據(jù)是：訪問內(nèi)存時，通過比較訪問的內(nèi)存和程序?qū)嶋H分配的內(nèi)存，驗證內(nèi)存訪問的有效性，從而在bug發(fā)生時就檢測到它們，而不會等到副作用產(chǎn)生時才有所察覺。

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

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

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

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

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

追蹤受限內(nèi)存

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

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

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

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

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

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

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

如何使用？

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

編譯，通過Address Sanitizer運行：

程序立馬crash，輸出很多內(nèi)容：

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

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

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

錯誤的內(nèi)存訪問只是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); 
 
        } 
 
    } 

運行代碼：

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

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

結(jié)論

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