在Xcode 7上直接使用Address Sanitizer

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

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

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

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

記憶體安全是一個主要的問題。C語言中根本沒有記憶體安全可言。像下面的程式碼，會被正常的編譯，而且可能正常執行：

這段程式碼只申請了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還提供了其他的消毒劑，使用它可以捕捉許多不明確行為。以下是例項程式：

執行程式碼：

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

這裡並不像地址消毒劑那樣輸出額外的資訊，但是，在出現錯誤的時候，程式立即停止了執行，而且我們通過除錯工具可以很簡單地查詢問題。
不明確行為消毒劑暫時未整合到Xcode中，但是你可以在工程的build settings中新增compiler flags來使用。

結論

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