[[143029]]

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

C語言中一種異常危險(xiǎn)的情況

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

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

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

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

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

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

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

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

內(nèi)存訪問驗(yàn)證

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

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

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

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

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

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

追蹤受限內(nèi)存

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

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

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

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

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

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

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

如何使用？

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

編譯，通過Address Sanitizer運(yùn)行：

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

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

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

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

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

#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); 
 
        } 
 
    } 

運(yùn)行代碼：

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

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

結(jié)論

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