國慶長假終于結(jié)束了，從擁堵的噩夢中醒來，該收收心重新回到工作中來了（順便吐槽一下鬧心的長假，平時工作沒時間出去，放了長假了 又不敢出去，路上耗費大量的時間和金錢也算了，弄的整個人也身心疲憊的……）
言歸正傳，接著上回宕機情況說。之前比較難找的宕機錯誤已經(jīng)在前兩篇隨筆里說過了，這次要說的是前不久一個同事遇到的。他要做一個錄像功能，每次把客戶端的消息轉(zhuǎn)儲成文件時掛掉。大致代碼如下：
1 /**
2 *\author peakflys
3 *\brief 堆棧崩潰問題
4 */
5 #include <iostream>
6 #include <fstream>
7 using namespace std;
8
9 const unsigned int DATA_BUFFER = 64 * 1024;
10
11 class Test
12 {
13 public:
14 Test(const string _name) : name(_name)
15 {
16 }
17 void test();
18 private:
19 string name;
20 };
21
22 void Test::test()
23 {
24 ofstream out(name.c_str(),ios_base::binary);
25 if(!out)
26 return;
27 cout<<name<<endl;
28 char data[DATA_BUFFER * 1024];
29 bzero(data,sizeof(data));
30 }
31
32 int main()
33 {
34 Test t("test");
35 t.test();
36 return 0;
37 }
每次宕機的情況和上面示例中test函數(shù)大致相同，都在第24行掛掉(此例子在我本地虛擬機上是掛在第22行)，可能大家看到這個例子就知道原因了，但是實際項目代碼比這個復(fù)雜的多、也隱蔽的多，core文件顯示不出宕機的具體情況，堆棧沒被破壞，但是也沒有實際可用的信息。單步跟進去每次都是到創(chuàng)建
ofstream 對象時掛掉。剛開始懷疑是文件名字的問題，因為錄像文件名稱是一個std::string，它是經(jīng)過幾部分最終拼接成的，所以我一直在查看前面的代碼，檢查之后看不出有什么問題，下斷點，在函數(shù)調(diào)用前發(fā)現(xiàn)一切數(shù)據(jù)都是正常的，這就奇怪了？為什么程序每次都是在運行到創(chuàng)建
ofstream 對象時直接報內(nèi)存非法訪問的段錯誤?
當(dāng)時的思路剛開始覺得既然是在函數(shù)內(nèi)掛掉的，肯定是函數(shù)內(nèi)前面執(zhí)行的代碼引起的問題，但是宕機的位置是在函數(shù)內(nèi)第一行，況且沒有參數(shù)的傳遞，所以就沒有能影響這行代碼的可能，然后懷疑是其他線程造成的(程序環(huán)境是多線程的)，但是查看了一下，這個類的所有操作的執(zhí)行只在一個線程內(nèi)調(diào)用。這就比較詭異了……
因為
當(dāng)時有點其他的工作要處理，并且那個同事宕機執(zhí)行的代碼要經(jīng)過好多操作才會執(zhí)行，每次調(diào)試起來也不方便，所以就先放下了。第二天來到時，看到他還在為那個問題糾結(jié)，他想了很多辦法，包括把文件名直接寫死、文件名改為字符數(shù)組等等，都沒用，問題依然存在。當(dāng)時感覺應(yīng)該是函數(shù)內(nèi)代碼的問題，大致看了一下函數(shù)后面的代碼，也沒發(fā)現(xiàn)什么問題，就是把一些數(shù)據(jù)序列化成二進制，然后創(chuàng)建一個數(shù)組，把客戶端發(fā)來的消息序列化進去，最后都寫入文件，但是究竟哪里引起的宕機還真不清楚。后來我讓他把序列化客戶端消息的那幾行代碼注釋掉試試，結(jié)果函數(shù)執(zhí)行正常，沒有宕機。那看來就是這幾行代碼的問題，然后繼續(xù)縮小注釋范圍，最終大致定位到類似于上例中第28行處。計算了一下數(shù)據(jù)的大小，發(fā)現(xiàn)是64*1024*1024，總的大小也就是64M，馬上 ulimit -s
查看了一下當(dāng)前線程的堆棧上限，顯示10240，這時候明白是怎么回事了，用戶態(tài)堆棧大小為64M超出了線程默認(rèn)的最大值10M(ulimit指令顯示的單位是KB)。具體宕機情況可以通過上面示例跟蹤時的匯編來模擬。具體如下：
0x0000000000400c54 <_ZN4Test4testEv+0>: push %rbp
0x0000000000400c55 <_ZN4Test4testEv+1>: mov %rsp,%rbp
0x0000000000400c58 <_ZN4Test4testEv+4>: push %rbx
0x0000000000400c59 <_ZN4Test4testEv+5>: sub $0x10000218,%rsp
0x0000000000400c60 <_ZN4Test4testEv+12>: mov %rdi,-0x10000218(%rbp)
0x0000000000400c67 <_ZN4Test4testEv+19>: mov -0x10000218(%rbp),%rdi
0x0000000000400c6e <_ZN4Test4testEv+26>: callq 0x4009f0 <_ZNKSs5c_strEv@plt>
0x0000000000400c73 <_ZN4Test4testEv+31>: mov %rax,%rsi
0x0000000000400c76 <_ZN4Test4testEv+34>: lea -0x210(%rbp),%rdi
0x0000000000400c7d <_ZN4Test4testEv+41>: mov $0x4,%edx
0x0000000000400c82 <_ZN4Test4testEv+46>: callq 0x400ac0 <_ZNSt14basic_ofstreamIcSt11char_traitsIcEEC1EPKcSt13_Ios_Openmode@plt>
0x0000000000400c87 <_ZN4Test4testEv+51>: lea -0x210(%rbp),%rax
0x0000000000400c8e <_ZN4Test4testEv+58>: lea 0xf8(%rax),%rdi
0x0000000000400c95 <_ZN4Test4testEv+65>: callq 0x400a60 <_ZNKSt9basic_iosIcSt11char_traitsIcEEntEv@plt>
0x0000000000400c9a <_ZN4Test4testEv+70>: test %al,%al
0x0000000000400c9c <_ZN4Test4testEv+72>: je 0x400ca0 <_ZN4Test4testEv+76>
0x0000000000400c9e <_ZN4Test4testEv+74>: jmp 0x400d06 <_ZN4Test4testEv+178>
0x0000000000400ca0 <_ZN4Test4testEv+76>: mov -0x10000218(%rbp),%rsi
0x0000000000400ca7 <_ZN4Test4testEv+83>: mov $0x6013c0,%edi
0x0000000000400cac <_ZN4Test4testEv+88>: callq 0x400a90 <_ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKSbIS4_S5_T1_E@plt>
程序停在
0x0000000000400c60 位置，在rdi寄存器保存時掛掉，原因很簡單，是因為函數(shù)內(nèi)棧地址空間溢出，導(dǎo)致rdi保存位置非法。
這類宕機的特點：宕機位置在函數(shù)執(zhí)行處或者函數(shù)執(zhí)行的第一行，而且是必宕，core文件基本看不出什么(info locals指令有時可以顯示出異常數(shù)據(jù)
)。解決方法：一、縮小數(shù)據(jù)大小，分批序列化；二、增大默認(rèn)的棧地址空間。采納第一種，重新編譯、運行，一切正常。至此問題算是解決了。本來這種函數(shù)棧溢出引起的宕機應(yīng)該很容易想到的，但是在我們項目開發(fā)中還沒遇到過，因為當(dāng)時定義的最大處理數(shù)據(jù)長度是64K，以宏的方式定義，以后使用時 如果數(shù)據(jù)大于這個宏，就把數(shù)據(jù)分隔，分批使用，奈何當(dāng)時同事使用時直接把那個宏數(shù)據(jù)大小又放大了一個數(shù)量級，而且當(dāng)時代碼寫的挺隱蔽，也很靠后，數(shù)組定義時大小問題也就沒太在意。 最后還是要特別說一下，數(shù)組是除了野指針引起的宕機外，其他通過core文件看不出宕機原因的諸多詭異問題的最大元兇。
至此詭異的宕機問題基本先告一段落，以后有時間再總結(jié)一下野指針宕機的一些心得。 ---peakflys