最近項目開始集中測試了，服務器程序經常crash，由于服務器一般情況下都是關閉了core的，所以好幾次都只能通過雜亂的日志來定位問題。
當然，我們可以通過ulimit來打開core開關，不過這可能帶來新的問題：我們的服務器程序每個core文件大概有1G多，測試期間如果頻繁crash,沒有注意及時清理，一不小心就會把磁盤寫滿，
而且core文件畢竟是和進程程序相關的，有時候找相應版本也是個麻煩事。

能否在程序crash的時候，將callStack以及參數和局部變量都記錄到日志里？
這個技術其實在游戲客戶端已經用了很多年了，一般游戲客戶端crash后，都會彈出一個是否發送錯誤的選擇框，其實就是發送的CallStack的日志和MiniDUmp文件。
要想記錄CallStack就必然涉及到Stack的遍歷，linux下的Stack遍歷使用很簡單，簡單的backtrace就可以搞定，man backtrace就有現成的例子，
這比windows下復雜的頭疼的StackWalk好用的多。

解決了Stack遍歷問題后，還剩下一個問題：如何在程序crash的時候得到通知執行我們自己的dump代碼？
在Windwos下有SEH異常來實現這個功能，而linux下可以通過使用信號在進程crash的時候執行自己的處理代碼。

好了，開始寫個簡單代碼測試下:
首先設置幾個主要crash信號的處理函數
signal(SIGSEGV, &DumpHelper::OnCrash);
signal(SIGABRT, &DumpHelper::OnCrash);
signal(SIGFPE, &DumpHelper::OnCrash);

在OnCrash里我們用前面提到的backtrace系列函數，來記錄堆棧:
void* szStackFrame[100];
int nFrameCount = backtrace(szStackFrame, 100);
char** strFrameInfo = backtrace_symbols(szStackFrame, nFrameCount); 
char szDumpFileName[1024] = {0};
snprintf(szDumpFileName, sizeof(szDumpFileName), "dump_%u.log", (unsigned int)time(NULL) );
FILE* pFile = fopen(szDumpFileName, "wb");
if(!pFile) return;
for(int i = 0; i < nFrameCount; i++)
{
    fprintf(pFile, "%s\n", strFrameInfo[i]);
}
fclose(pFile);
free(strFrameInfo);

接著，設置幾個嵌套調用的函數：
void fun()
{
 //assert(0);
 int* p = NULL;
 *p =3;
}

void fun1()
{
 fun();
}

void fun2()
{
 fun1();
}

void fun3()
{
 fun2();
}

最后，我們在main函數里執行fun3,注意編譯的時候帶上-rdynamic 選項。

運行下，果然可以打印基本的堆棧，不過馬上，發現了新的問題：這個堆棧信息也太簡陋了，只有調用函數的名字，其余的參數、局部變量完全沒有，
這個和gdb能看到的callStack差距也太大了。
解決這個問題最簡單的辦法就是用gdb來打印堆棧,在這里，gdb和其他程序有區別，如果你試圖通過 echo "bt"|gdb -p XXX>a.txt來獲得堆棧，那將會非常失望，
根本不起作用，google了下，基本沒什么解決辦法。
不過gdb 可以從文件讀入指令，例如 gdb XXX<cmddata，這給了我們機會，
system("echo  \"bt full|gcore\">testcmd");
  char dbx[160]={0};
     sprintf(dbx, "gdb -p %d ./main<testcmd >gdbdump_%d.log", getpid(), getpid() );
  system(dbx);

測試運行，發現可以打印詳細的堆棧，不過，要求機器上有gdb.
上面的命令還dump了一個core文件，不過這個core文件的堆棧信息是錯誤的，我不知道為什么。。。。

多線程環境下使用上述辦法，只能輸出一個線程的堆棧，需要先獲取線程數目，然后逐個線程打印堆棧。

最后，為了避免影響正常的coredump,要在OnCrash的處理函數里將信號的處理函數設置為默認。
如果我一定要有core呢，setrlimit吧，去掉core限制即可。