摘要：一個有意思的 Crash 探究過程，Clang 有 GCC 沒有

> 本文首發於 Nebula Graph 官方部落格：[https://nebula-graph.com.cn/posts/troubleshooting-crash-clang-compiler-optimization/](https://nebula-graph.com.cn/posts/troubleshooting-crash-clang-compiler-optimization/)

![troubleshooting-crash-clang-compiler-optimization](https://www-cdn.nebula-graph.com.cn/nebula-blog/troubleshooting-crash-clang-compiler-optimization.png)

如果有人告訴你，下面的 C++ 函式會導致程式 crash，你會想到哪些原因呢？

```cpp
std::string b2s(bool b) {
    return b ? "true" : "false";
}
```

如果再多給一些描述，比如：

- Crash 以一定的機率復現
- Crash 原因是段錯誤（SIGSEGV）
- 現場的 Backtrace 經常是不完整甚至完全丟失的。
- 只有最佳化級別在 -O2 以上才會（更容易）復現
- 僅在 Clang 下復現，GCC 復現不了

好了，一些老鳥可能已經有線索了，下面給出一個最小化的復現程式和步驟：

```cpp
// file crash.cpp
#include <iostream>
#include <string>

std::string __attribute__((noinline)) b2s(bool b) {
    return b ? "true" : "false";
}

union {
    unsigned char c;
    bool b;
} volatile u;

int main() {
    u.c = 0x80;
    std::cout << b2s(u.b) << std::endl;
    return 0;
}
```

```
$ clang++ -O2 crash.cpp
$ ./a.out
truefalse,d$x4DdzRx

Segmentation fault (core dumped)

$ gdb ./a.out core.3699
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000012cfffff0d4 in ?? ()
(gdb) bt
#0  0x0000012cfffff0d4 in ?? ()
#1  0x00000064fffff0f4 in ?? ()
#2  0x00000078fffff124 in ?? ()
#3  0x000000b4fffff1e4 in ?? ()
#4  0x000000fcfffff234 in ?? ()
#5  0x00000144fffff2f4 in ?? ()
#6  0x0000018cfffff364 in ?? ()
#7  0x0000000000000014 in ?? ()
#8  0x0110780100527a01 in ?? ()
#9  0x0000019008070c1b in ?? ()
#10 0x0000001c00000010 in ?? ()
#11 0x0000002ffffff088 in ?? ()
#12 0xe2ab001010074400 in ?? ()
#13 0x0000000000000000 in ?? ()
```

因為 backtrace 資訊不完整，說明程式並不是在第一時間 crash 的。面對這種情況，為了快速找出第一現場，我們可以試試 AddressSanitizer（ASan）：

```
$ clang++ -g -O2 -fno-omit-frame-pointer -fsanitize=address crash.cpp
$ ./a.out
=================================================================
==3699==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000552805 at pc 0x0000004ff83a bp 0x7ffd7610d240 sp 0x7ffd7610c9f0
READ of size 133 at 0x000000552805 thread T0
    #0 0x4ff839 in __asan_memcpy (a.out+0x4ff839)
    #1 0x5390a7 in b2s[abi:cxx11](bool) crash.cpp:6
    #2 0x5391be in main crash.cpp:16:18
    #3 0x7faed604df42 in __libc_start_main (/usr/lib64/libc.so.6+0x23f42)
    #4 0x41c43d in _start (a.out+0x41c43d)

0x000000552805 is located 59 bytes to the left of global variable '<string literal="">' defined in 'crash.cpp:6:25' (0x552840) of size 6
  '<string literal="">' is ascii string 'false'
0x000000552805 is located 0 bytes to the right of global variable '<string literal="">' defined in 'crash.cpp:6:16' (0x552800) of size 5
  '<string literal="">' is ascii string 'true'
SUMMARY: AddressSanitizer: global-buffer-overflow (/home/dutor.hou/Wdir/nebula-graph/build/bug/a.out+0x4ff839) in __asan_memcpy
Shadow bytes around the buggy address:
…
...
```

從 ASan 給出的資訊，我們可以定位到是函式 `b2s(bool)` 在讀取字串常量 `"true"` 的時候，發生了“全域性緩衝區溢位”。好了，我們再次以上帝視角審視一下問題函式和復現程式，“似乎”可以得出結論：因為 `b2s` 的布林型別引數 `b` 沒有初始化，所以 `b` 中儲存的是一個 `0` 和 `1` 之外的值[1]。那麼問題來了，為什麼 `b` 的這種取值會導致“緩衝區溢位”呢？感興趣的可以將 `b` 的型別由 `bool` 改成 `char` 或者 `int`，問題就可以得到修復。

想要解答這個問題，我們不得不看下 clang++ 為 `b2s` 生成了怎樣的指令（之前我們提到 GCC 下沒有出現 crash，所以問題可能和程式碼生成有關）。在此之前，我們應該瞭解：

- 樣例程式中，`b2s` 的返回值是一個臨時的 `std::string` 物件，是儲存在棧上的
- C++ 11 之後，GCC 的 `std::string` 預設實現使用了 SBO（Small Buffer Optimization），其定義大致為 `std::string{ char *ptr; size_t size; union{ char buf[16]; size_t capacity}; }`。對於長度小於 `16` 的字串，不需要額外申請記憶體。

OK，那我們現在來看一下 `b2s` 的反彙編並給出關鍵註解：

```
(gdb) disas b2s
Dump of assembler code for function b2s[abi:cxx11](bool):
   0x00401200 :     push   %r14
   0x00401202 :     push   %rbx
   0x00401203 :     push   %rax
   0x00401204 :     mov    %rdi,%r14         # 將返回值(string)的起始地址儲存到 r14
   0x00401207 :     mov    $0x402010,%ecx    # 將 "true" 的起始地址儲存至 ecx
   0x0040120c :    mov    $0x402015,%eax    # 將 "false" 的起始地址儲存至 eax
   0x00401211 :    test   %esi,%esi         # “測試” 引數 b 是否非零
   0x00401213 :    cmovne %rcx,%rax         # 如果 b 非零，則將 "true" 地址儲存至 rax
   0x00401217 :    lea    0x10(%rdi),%rdi   # 將 string 中的 buf 起始地址儲存至 rdi
                                                 # （同時也是後面 memcpy 的第一個引數）
   0x0040121b :    mov    %rdi,(%r14)       # 將 rdi 儲存至 string 的 ptr 欄位，即 SBO
   0x0040121e :    mov    %esi,%ebx         # 將 b 的值儲存至 ebx
   0x00401220 :    xor    $0x5,%rbx         # 將 0x5 異或到 rbx（也即 ebx）
                                                 # 注意，如果 rbx 非 0 即 1，那麼 rbx 儲存的就是 4 或 5，
                                                 # 即 "true" 或 "false" 的長度 
   0x00401224 :    mov    %rax,%rsi         # 將字串起始地址儲存至 rsi，即 memcpy 的第二個引數
   0x00401227 :    mov    %rbx,%rdx         # 將字串的長度儲存至 rdx，即 memcpy 的第三個引數
   0x0040122a :    callq  <memcpy>      # 呼叫 memcpy
   0x0040122f :    mov    %rbx,0x8(%r14)    # 將字串長度儲存到 string::size
   0x00401233 :    movb   $0x0,0x10(%r14,%rbx,1)  # 將 string 以 '\0' 結尾
   0x00401239 :    mov    %r14,%rax         # 將 string 地址儲存至 rax，即返回值
   0x0040123c :    add    $0x8,%rsp
   0x00401240 :    pop    %rbx
   0x00401241 :    pop    %r14
   0x00401243 :    retq
End of assembler dump.
```

到這裡，問題就無比清晰了：

1. clang++ 假設了 `bool` 型別的值非 `0` 即 `1`
1. 在編譯期，`”true”` 和 `”false”` 長度已知
1. 使用異或指令（ `0x5 ^ false == 5`, `0x5 ^ true == 4`）計算要複製的字串的長度
1. 當 `bool` 型別不符合假設時，長度計算錯誤
1. 因為 `memcpy` 目標地址在棧上（僅對本例而言），因此棧上的緩衝區也可能溢位，從而導致程式跑飛，backtrace 缺失。

注：

1. C++ 標準要求 `bool` 型別至少_能夠_表示兩個狀態： `true` 和 `false` ，但並沒有規定 `sizeof(bool)` 的大小。但在幾乎所有的編譯器實現上， `bool` 都佔用一個定址單位，即位元組。因此，從儲存角度，取值範圍為  `0x00-0xFF`，即 `256` 個狀態。

喜歡這篇文章？來來來，給我們的 [GitHub](https://github.com/vesoft-inc/nebula) 點個 star 表鼓勵啦~~ ?‍♂️?‍♀️ [手動跪謝]

交流圖資料庫技術？交個朋友，Nebula Graph 官方小助手微信：[NebulaGraphbot](https://www-cdn.nebula-graph.com.cn/nebula-blog/nbot.png) 拉你進交流群~~

## 推薦閱讀

- [一次 Segmentation Fault 和 GCC Illegal Instruction 編譯問題排查](https://nebula-graph.com.cn/posts/segmentation-fault-gcc-illegal-instruction-trouble-shooting/)</memcpy></string></string></string></string></string></iostream>

記一起由 Clang 編譯器最佳化觸發的 Crash

相關文章