國慶長假終于結(jié)束了，從擁堵的噩夢(mèng)中醒來，該收收心重新回到工作中來了（順便吐槽一下鬧心的長假，平時(shí)工作沒時(shí)間出去，放了長假了 又不敢出去，路上耗費(fèi)大量的時(shí)間和金錢也算了，弄的整個(gè)人也身心疲憊的……）
言歸正傳，接著上回宕機(jī)情況說。之前比較難找的宕機(jī)錯(cuò)誤已經(jīng)在前兩篇隨筆里說過了，這次要說的是前不久一個(gè)同事遇到的。他要做一個(gè)錄像功能，每次把客戶端的消息轉(zhuǎn)儲(chǔ)成文件時(shí)掛掉。大致代碼如下：
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 }
每次宕機(jī)的情況和上面示例中test函數(shù)大致相同，都在第24行掛掉(此例子在我本地虛擬機(jī)上是掛在第22行)，可能大家看到這個(gè)例子就知道原因了，但是實(shí)際項(xiàng)目代碼比這個(gè)復(fù)雜的多、也隱蔽的多，core文件顯示不出宕機(jī)的具體情況，堆棧沒被破壞，但是也沒有實(shí)際可用的信息。單步跟進(jìn)去每次都是到創(chuàng)建
ofstream 對(duì)象時(shí)掛掉。剛開始懷疑是文件名字的問題，因?yàn)殇浵裎募Q是一個(gè)std::string，它是經(jīng)過幾部分最終拼接成的，所以我一直在查看前面的代碼，檢查之后看不出有什么問題，下斷點(diǎn)，在函數(shù)調(diào)用前發(fā)現(xiàn)一切數(shù)據(jù)都是正常的，這就奇怪了？為什么程序每次都是在運(yùn)行到創(chuàng)建
ofstream 對(duì)象時(shí)直接報(bào)內(nèi)存非法訪問的段錯(cuò)誤?
當(dāng)時(shí)的思路剛開始覺得既然是在函數(shù)內(nèi)掛掉的，肯定是函數(shù)內(nèi)前面執(zhí)行的代碼引起的問題，但是宕機(jī)的位置是在函數(shù)內(nèi)第一行，況且沒有參數(shù)的傳遞，所以就沒有能影響這行代碼的可能，然后懷疑是其他線程造成的(程序環(huán)境是多線程的)，但是查看了一下，這個(gè)類的所有操作的執(zhí)行只在一個(gè)線程內(nèi)調(diào)用。這就比較詭異了……
因?yàn)?span style="font-size: 13px; background-color: #eeeeee; ">當(dāng)時(shí)有點(diǎn)其他的工作要處理，并且那個(gè)同事宕機(jī)執(zhí)行的代碼要經(jīng)過好多操作才會(huì)執(zhí)行，每次調(diào)試起來也不方便，所以就先放下了。第二天來到時(shí)，看到他還在為那個(gè)問題糾結(jié)，他想了很多辦法，包括把文件名直接寫死、文件名改為字符數(shù)組等等，都沒用，問題依然存在。當(dāng)時(shí)感覺應(yīng)該是函數(shù)內(nèi)代碼的問題，
大致看了一下函數(shù)后面的代碼，也沒發(fā)現(xiàn)什么問題，就是把一些數(shù)據(jù)序列化成二進(jìn)制，然后創(chuàng)建一個(gè)數(shù)組，把客戶端發(fā)來的消息序列化進(jìn)去，最后都寫入文件，但是究竟哪里引起的宕機(jī)還真不清楚。后來我讓他把序列化客戶端消息的那幾行代碼注釋掉試試，結(jié)果函數(shù)執(zhí)行正常，沒有宕機(jī)。那看來就是這幾行代碼的問題，然后繼續(xù)縮小注釋范圍，最終大致定位到類似于上例中第28行處。計(jì)算了一下數(shù)據(jù)的大小，發(fā)現(xiàn)是64*1024*1024，總的大小也就是64M，馬上 ulimit -s
查看了一下當(dāng)前線程的堆棧上限，顯示10240，這時(shí)候明白是怎么回事了，用戶態(tài)堆棧大小為64M超出了線程默認(rèn)的最大值10M(ulimit指令顯示的單位是KB)。具體宕機(jī)情況可以通過上面示例跟蹤時(shí)的匯編來模擬。具體如下：
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í)掛掉，原因很簡單，是因?yàn)楹瘮?shù)內(nèi)棧地址空間溢出，導(dǎo)致rdi保存位置非法。
這類宕機(jī)的特點(diǎn)：宕機(jī)位置在函數(shù)執(zhí)行處或者函數(shù)執(zhí)行的第一行，而且是必宕，core文件基本看不出什么(info locals指令有時(shí)可以顯示出異常數(shù)據(jù)
)。解決方法：一、縮小數(shù)據(jù)大小，分批序列化；二、增大默認(rèn)的棧地址空間。采納第一種，重新編譯、運(yùn)行，一切正常。至此問題算是解決了。本來這種函數(shù)棧溢出引起的宕機(jī)應(yīng)該很容易想到的，但是在我們項(xiàng)目開發(fā)中還沒遇到過，因?yàn)楫?dāng)時(shí)定義的最大處理數(shù)據(jù)長度是64K，以宏的方式定義，以后使用時(shí) 如果數(shù)據(jù)大于這個(gè)宏，就把數(shù)據(jù)分隔，分批使用，奈何當(dāng)時(shí)同事使用時(shí)直接把那個(gè)宏數(shù)據(jù)大小又放大了一個(gè)數(shù)量級(jí)，而且當(dāng)時(shí)代碼寫的挺隱蔽，也很靠后，數(shù)組定義時(shí)大小問題也就沒太在意。 最后還是要特別說一下，數(shù)組是除了野指針引起的宕機(jī)外，其他通過core文件看不出宕機(jī)原因的諸多詭異問題的最大元兇。
至此詭異的宕機(jī)問題基本先告一段落，以后有時(shí)間再總結(jié)一下野指針宕機(jī)的一些心得。 ---peakflys