? ? ? ? 這個bug的誕生源于項目中使用了一個開源C庫。由于對該C庫API不熟悉，一個不起眼的錯誤調用，導致一系列詭異的問題。最終經過調試，我們發現發生了內存覆蓋問題。為了直達問題根節，我將問題代碼簡化如下（轉載請指明出于breaksoftware的csdn博客）

#include <iostream>
#include <stdarg.h>enum type {PARAM,RESULT
};void set_zero(type t, ...) {va_list arg;va_start(arg, t);if (PARAM == t) {long* param_longp = va_arg(arg, long *);*param_longp = 0;} else {int* param_intp = va_arg(arg, int *);*param_intp = 0;}va_end(arg);
}int main() {int x = 1;int y = 2;set_zero(PARAM, &y);std::cout << "x = " << x << "; y = " << y << std::endl;return 0;
}

? ? ? ? 如果只是簡單看一下main函數，可以認為輸出是

x = 1; y = 0

? ? ? ? 然而實際輸出是

x = 0; y = 0

? ? ? ? 是不是很詭異？我們在main函數中只是把y的值從2修改成0，根本沒有“動”過x變量。但是最終x的值變成了0。

? ? ? ? 由于示例足夠簡單，我們可以通過閱讀源碼來定位問題。第26行傳遞的參數y是4個字節的int類型。而在第13行，發現參數被當成8個字節的long類型設置為0，這樣就覆蓋了y空間之后的4個字節。而x變量正好在內存上位于y變量之后，這樣x的值也會被改成0。

? ? ? ? 現實中，我們的場景比較復雜，最終我們通過GDB來確定該問題。其過程大致如下

Reading symbols from ./test...done.
(gdb) b 26
Breakpoint 1 at 0xb0a: file main.cpp, line 26.
(gdb) r
Starting program: /home/fangliang/projects/test_cover/test Breakpoint 1, main () at main.cpp:26
26              set_zero(PARAM, &y);
(gdb) p &x
$1 = (int *) 0x7fffffffe434
(gdb) p x
$2 = 1
(gdb) p &y
$3 = (int *) 0x7fffffffe430
(gdb) p y
$4 = 2
(gdb) x/2x &y
0x7fffffffe430: 0x00000002      0x00000001
(gdb) awatch x
Hardware access (read/write) watchpoint 2: x
(gdb) c
Continuing.Hardware access (read/write) watchpoint 2: xOld value = 1
New value = 0
set_zero (t=PARAM) at main.cpp:21
21      }
(gdb) disas
……0x0000555555554a64 <+234>:   mov    -0xd8(%rbp),%rax0x0000555555554a6b <+241>:   movq   $0x0,(%rax)
=> 0x0000555555554a72 <+248>:   jmp    0x555555554acb <set_zero(type, ...)+337>
……0x0000555555554acb <+337>:   nop0x0000555555554acc <+338>:   mov    -0xb8(%rbp),%rax
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) i r rax 
rax            0x7fffffffe430   140737488348208
(gdb) x/2x 0x7fffffffe430
0x7fffffffe430: 0x00000000      0x00000000

? ? ? ? 第2行在代碼第26行下了斷點，為了讓我們可以在main函數中查看x、y變量的地址和值。

? ? ? ? 第10,14和18行可以看出x和y變量的內存空間是連續的。

? ? ? ? 第19行我們給“莫名”被修改的變量x下了內存讀寫斷點。執行continue后，由于x的值被從1改成0，從而觸發了斷點。

? ? ? ? 第30行，我們查看當前代碼處的匯編指令。

? ? ? ? 第33行，是觸發內存斷點，即x的值被修改的位置。movq是給8個字節賦值，于是我們只要驗證rax地址是否就是y變量的地址。

? ? ? ? 第41行驗證了rax地址就是y變量地址，從而可以證明就是movq ? $0x0,(%rax)導致x變量值被改變。

? ? ? ? 第43行，我們查看此時x和y的內存空間的值，它們已經都是0了。

? ? ? ? 如果我們把set_zero方法改成針對y變量的函數

void set_param(long* param_longp) {*param_longp = 0;
}

? ? ? ? 這樣如果我們給其傳遞int型變量，編譯器就會報錯

main.cpp: In function ‘int main()’:
main.cpp:30:14: error: cannot convert ‘int*’ to ‘long int*’ for argument ‘1’ to ‘void set_param(long int*)’set_param(&y);

? ? ? ? 而使用可變長參數則正好掩蓋了該問題。

總結

以上是生活随笔為你收集整理的bug诞生记——不定长参数隐藏的类型问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。