# 應用 AddressSanitizer 發現程式記憶體錯誤

![AddressSanitizer.png](https://user-images.githubusercontent.com/56643819/74794701-d829a480-52fe-11ea-8fe7-6bd98a95dc39.png)

作為 C/ C++ 工程師，在開發過程中會遇到各類問題，最常見便是**記憶體使用問題**，比如，**越界**，**洩漏。**過去常用的工具是 Valgrind，但使用 Valgrind 最大問題是它會極大地降低程式執行的速度，初步估計會降低 10 倍執行速度。而 Google 開發的 [AddressSanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer) 這個工具很好地解決了 Valgrind 帶來效能損失問題，它非常快，只拖慢程式 2 倍速度。

## AddressSanitizer 概述

AddressSanitizer 是一個基於編譯器的測試工具，可在執行時檢測 C/C++ 程式碼中的多種記憶體錯誤。嚴格上來說，AddressSanitizer 是一個編譯器外掛，它分為兩個模組，一個是編譯器的 instrumentation 模組，一個是用來替換 malloc/free 的動態庫。

Instrumentation 主要是針對在 llvm 編譯器級別對訪問記憶體的操作（store，load，alloc等），將它們進行處理。動態庫主要提供一些執行時的複雜的功能（比如 poison/unpoison shadow memory）以及將 malloc/free 等系統呼叫函式 hook 住。

### AddressSanitizer 基本使用

根據 AddressSanitizer Wiki 可以檢測下面這些記憶體錯誤
- Use after free：訪問堆上已經被釋放的記憶體
- Heap buffer overflow：堆上緩衝區訪問溢位
- Stack buffer overflow：棧上緩衝區訪問溢位
- Global buffer overflow：全域性緩衝區訪問溢位
- Use after return：訪問棧上已被釋放的記憶體
- Use after scope：棧物件使用超過定義範圍
- Initialization order bugs：初始化命令錯誤
- Memory leaks：記憶體洩漏

這裡我只簡單地介紹下基本的使用，詳細的使用文件可以看官方的編譯器使用文件，比如 [Clang](https://clang.llvm.org/docs/AddressSanitizer.html) 的文件：[https://clang.llvm.org/docs/AddressSanitizer.html](https://clang.llvm.org/docs/AddressSanitizer.html)

<a name="pCh3U" rel="nofollow"></a>
#### Use after free 實踐例子
下面這段程式碼是一個很簡單的 Use after free 的例子：

```cpp
//use_after_free.cpp
#include <iostream>
int main(int argc, char **argv) {
  int *array = new int[100];
  delete [] array;
  std::cout << array[0] << std::endl;
  return 1;
}
```

編譯程式碼，並且執行，這裡可以看到只需要在編譯的時候帶上 `-fsanitize=address`  選項就可以了。

```shell
clang++  -O -g -fsanitize=address ./use_after_free.cpp
./a.out
```

最終我們會看到如下的輸出：

```
==10960==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000000040 at pc 0x00010d471df0 bp 0x7ffee278e6b0 sp 0x7ffee278e6a8
READ of size 4 at 0x614000000040 thread T0
    #0 0x10d471def in main use_after_free.cpp:6
    #1 0x7fff732c17fc in start (libdyld.dylib:x86_64+0x1a7fc)

0x614000000040 is located 0 bytes inside of 400-byte region [0x614000000040,0x6140000001d0)
freed by thread T0 here:
    #0 0x10d4ccced in wrap__ZdaPv (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x51ced)
    #1 0x10d471ca1 in main use_after_free.cpp:5
    #2 0x7fff732c17fc in start (libdyld.dylib:x86_64+0x1a7fc)

previously allocated by thread T0 here:
    #0 0x10d4cc8dd in wrap__Znam (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x518dd)
    #1 0x10d471c96 in main use_after_free.cpp:4
    #2 0x7fff732c17fc in start (libdyld.dylib:x86_64+0x1a7fc)

SUMMARY: AddressSanitizer: heap-use-after-free use_after_free.cpp:6 in main
```

可以看到一目瞭然，非常清楚的告訴了我們在哪一行記憶體被釋放，而又在哪一行記憶體再次被使用。

還有一個是記憶體洩漏，比如下面的程式碼，顯然 p 所指的記憶體沒有被釋放。

```c
void *p;

int main() {
        p = malloc(7);
        p = 0; // The memory is leaked here.
        return 0;
}
```

編譯然後執行

```
clang -fsanitize=address -g  ./leak.c
./a.out
```

可以看到如下的結果

```
=================================================================
==17756==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 7 byte(s) in 1 object(s) allocated from:
    #0 0x4ffc80 in malloc (/home/simon.liu/workspace/a.out+0x4ffc80)
    #1 0x534ab8 in main /home/simon.liu/workspace/./leak.c:4:8
    #2 0x7f127c42af42 in __libc_start_main (/usr/lib64/libc.so.6+0x23f42)

SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).
```

不過這裡要注意**記憶體洩漏的檢測只會在程式最後退出之前進行檢測**，也就是說如果你在執行時如果不斷地分配記憶體，然後在退出的時候對記憶體進行釋放，AddressSanitizer 將不會檢測到記憶體洩漏，這種時候可能你就需要另外的工具了 JeMalloc / TCMalloc。

### AddressSanitizer 基本原理

這裡簡單介紹一下 AddressSanitizer 的實現，更詳細的演算法實現可以看《[AddressSanitizer: a fast address sanity checker](https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf)》：[https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf](https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf)

AddressSanitizer 會替換你的所有 malloc 以及 free，然後已經被分配（malloc）的記憶體區域的前後會被標記為 `poisoned` （主要是為了處理 overflow 這種情況)，而釋放（free）的記憶體會被標記為 poisoned（主要是為了處理 Use after free）。你的程式碼中的每一次的記憶體存取都會被編譯器做類似下面的翻譯.

before:

```c
*address = ...;  // or: ... = *address;
```

after:

```c
shadow_address = MemToShadow(address);
if (ShadowIsPoisoned(shadow_address)) {
  ReportError(address, kAccessSize, kIsWrite);
}
*address = ...;  // or: ... = *address;
```

這裡可以看到首先會對記憶體地址有一個翻譯（MemToShadow）的過程，然後再來判斷當所訪問的記憶體區域是否為 poisoned，如果是則直接報錯並退出。

這裡之所以會有這個翻譯是因為 AddressSanitizer 將虛擬記憶體分為了兩部分：

1. Main application memory（Mem）也就是被當前程式自身使用的記憶體
1. Shadow memory 簡單來說就是儲存了主存元資訊的一塊記憶體，比如主存的那些區域被 posioned 都是在 Shadow memory 中儲存的

### AddressSanitizer 和其他記憶體檢測工具對比
[下圖](https://github.com/google/sanitizers/wiki/AddressSanitizerComparisonOfMemoryTools#summary)是 AddressSanitizer 與其他的一些記憶體檢測工具的對比:

|  | [AddressSanitizer](AddressSanitizer) | [Valgrind/Memcheck](http://valgrind.org) | [Dr. Memory](http://dynamorio.org/drmemory.html) | [Mudflap](http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging) | Guard Page | [gperftools](https://github.com/gperftools/gperftools) |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| technology | CTI | DBI | DBI | CTI | Library | Library |
| ARCH | x86, ARM, PPC | x86, ARM, PPC, MIPS, S390X, TILEGX | x86 | all(?) | all(?) | all(?) |
| OS | Linux, OS X, Windows, FreeBSD, Android, iOS Simulator | Linux, OS X, Solaris, Android | Windows, Linux | Linux, Mac(?) | All (1) | Linux, Windows |
| Slowdown | **2x** | 20x | 10x | 2x-40x | ? | ? |
| Detects: |  |  |  |  |  |  |
| [Heap OOB](AddressSanitizerExampleHeapOutOfBounds) | **yes** | yes | yes | yes | some | some |
| [Stack OOB](AddressSanitizerExampleStackOutOfBounds) | **yes** | no | no | some | no | no |
| [Global OOB](AddressSanitizerExampleGlobalOutOfBounds) | **yes** | no | no | ? | no | no |
| [UAF](AddressSanitizerExampleUseAfterFree) | **yes** | yes | yes | yes | yes | yes |
| [UAR](AddressSanitizerExampleUseAfterReturn) | **yes** (see [AddressSanitizerUseAfterReturn](AddressSanitizerUseAfterReturn)) | no | no | no | no | no |
| UMR | no (see MemorySanitizer) | yes | yes | ? | no | no |
| Leaks | **yes** (see LeakSanitizer) | yes | yes | ? | no | yes |

引數說明：

- _**DBI**_: dynamic binary instrumentation（動態二進位制插樁）
- _**CTI**_: compile-time instrumentation （編譯時插樁）
- _**UMR**_: uninitialized memory reads （讀取未初始化的記憶體）
- _**UAF**_: use-after-free (aka dangling pointer) （使用釋放後的記憶體）
- _**UAR**_: use-after-return （使用返回後的值）
- _**OOB**_: out-of-bounds （溢位）
- _**x86**_: includes 32- and 64-bit.

可以看到相比於 Valgrind，AddressSanitizer 只會拖慢程式 2 倍執行速度。當前 AddressSanitizer 支援 GCC 以及 Clang，其中 GCC 是從 4.8 開始支援，而 Clang 的話是從 3.1 開始支援。

### AddressSanitizer 的使用注意事項

1. AddressSanitizer 在發現記憶體訪問違規時，應用程式並不會自動崩潰。這是由於在使用模糊測試工具時，它們通常都是透過檢查返回碼來檢測這種錯誤。當然，我們也可以在模糊測試進行之前透過將環境變數 ASAN_OPTIONS 修改成如下形式來迫使軟體崩潰：

```bash
export ASAN_OPTIONS='abort_on_error=1'/
```

2. AddressSanitizer 需要相當大的虛擬記憶體（大約 20 TB），不用擔心，這個只是虛擬記憶體，你仍可以使用你的應用程式。但像 american fuzzy lop 這樣的模糊測試工具就會對模糊化的軟體使用記憶體進行限制，不過你仍可以透過禁用記憶體限制來解決該問題。唯一需要注意的就是，這會帶來一些風險：測試樣本可能會導致應用程式分配大量的記憶體進而導致系統不穩定或者其他應用程式崩潰。因此在進行一些重要的模糊測試時，不要去嘗試在同一個系統上禁用記憶體限制。

## 在 Nebula Graph 中開啟 AddressSanitizer

我們在 Nebula Graph 中也使用了 AddressSanitizer，它幫助我們發現了非常多的問題。而在 Nebula Graph 中開啟 AddressSanitizer 很簡單，只需要在 Cmake 的時候帶上開啟 ENABLE_ASAN 這個 Option 就可以，比如:

```
Cmake -DENABLE_ASAN=On
```

這裡建議所有的開發者在開發完畢功能執行單元測試的時候都開啟 AddressSanitizer 來執行單元測試，這樣可以發現很多不容易發現的記憶體問題，節省很多除錯的時間。

## 附錄

- Nebula Graph：一個開源的分散式圖資料庫
- GitHub：[https://github.com/vesoft-inc/nebula](https://0x7.me/itpub2github)
- 知乎：[zhihu.com/org/nebulagraph/posts](https://www.zhihu.com/org/nebulagraph/posts)
- 微博：[weibo.com/nebulagraph](https://weibo.com/nebulagraph)

![關注公眾號](https://user-images.githubusercontent.com/56643819/69411505-0de2df80-0d48-11ea-88c0-444d157926f1.png)</iostream>

應用 AddressSanitizer 發現程式記憶體錯誤

相關文章