背景：

1.執行目標為MIPS機器，FLASH及RAM資源都非常緊張，無法執行帶除錯資訊的程式

2.程式有一定概率崩潰，從表現上難以分析

目標：

直接定位到崩潰目的碼

說明：

1、2在執行環境中操作，3、4在編譯環境中操作

1.設定核心轉儲

核心轉儲可以儲存程式崩潰時的記憶體狀態。是系統級別的實現。

檢視執行機器當前核心轉儲的設定：

#ulimit -a
-f: file size (blocks)             unlimited
-t: cpu time (seconds)             unlimited
-d: data seg size (kb)             unlimited
-s: stack size (kb)                8192
-c: core file size (blocks)        0
-m: resident set size (kb)         unlimited
-l: locked memory (kb)             64
-p: processes                      986
-n: file descriptors               1024
-v: address space (kb)             unlimited
-w: locks                          unlimited
-e: scheduling priority            0
-r: real-time priority             0
 

當前“core file size”為0，即未開啟。

設定為不限制，修改執行機器的/etc/profile：

#新增
ulimit -c unlimited

應用配置，在執行機器中執行：

#source /etc/profile

2.指定崩潰檔案生成路徑

預設崩潰檔案會生成在程式執行路徑下。程式佔用的記憶體越大，生成的崩潰檔案會越大。如果只需要部分記憶體段資訊，可以通過coredump_filter檔案指定。檔案位於/proc/<pid>/coredump_filter，預設值為0x23，數值含義如下：

(bit 0) anonymous private memory（匿名私有記憶體段）
(bit 1) anonymous shared memory（匿名共享記憶體段）
(bit 2) file-backed private memory（file-backed 私有記憶體段）
(bit 3) file-backed shared memory（file-bakced 共享記憶體段）
(bit 4) ELF header pages in file-backed private memory areas (it is effective only if the bit 2 is cleared)（ELF 檔案對映，只有在bit 2 復位的時候才起作用）
(bit 5) hugetlb private memory（大頁面私有記憶體）
(bit 6) hugetlb shared memory（大頁面共享記憶體）
 

這裡我們不做修改，我們去壓縮崩潰檔案來減小佔用體積。修改執行機器的/etc/sysctl.conf:

#新增
kernel.core_pattern = | /usr/sbin/core_gzip %e %p
kernel.core_uses_pid = 0

建立/usr/sbin/core_gzip指令碼：

#!/bin/sh

exec gzip -> /tmp/$1_$2.core.gz #注意路徑必須存在

修改檔案屬性:

#chmod +x /usr/sbin/core_gzip

這樣程式崩潰的時候會在執行機器的/tmp下生成例如prog_1480.core.gz檔案，檔名格式是由前面的%e %p指定的，具體引數含義如下：

%c 轉儲檔案的大小上限
%e 所dump的檔名
%g 所dump的程序的實際組ID
%h 主機名
%p 所dump的程序PID
%s 導致本次coredump的訊號
%t 轉儲時刻(由1970年1月1日起計的秒數)
%u 所dump程序的實際使用者ID

應用配置，在執行機器中執行：

#sysctl –p /etc/sysctl.conf

3.程式編譯註意事項

在本機使用交叉工具鏈編譯的時候需要生成2個檔案，一個是帶除錯資訊的，另外一個是我們實際執行的。方法如下：

1. 編譯選項加上-g生成了體積巨大的程式prog，我們備份為prog_debug，prog_debug是用來分析崩潰檔案的。
2. 在交叉工具鏈中找到mips_xxx_strip工具，執行#mips_xxx_strip prog得到去掉了除錯資訊的正常大小的prog

另外需要注意的是，為了讓程式能夠產生崩潰檔案，我們不能處理SIGQUIT，SIGILL，SIGABRT， SIGFPE和SIGSEGV這5個訊號。

4.定位崩潰

前面我們已經準備好了執行機器環境和帶除錯資訊的程式。等待程式崩潰後，我們從執行機器中拿到prog_1480.core.gz，#gzip -d prog_1480.core.gz解壓後得到prog_1480.core原始崩潰檔案。使用交叉工具鏈的mips_gdb工具執行：

#mips_xxx_gdb -ex bt prog_debug prog_1480.core

不出意外的話我們會看到崩潰程式碼和堆疊資訊(-ex bt表示在mips_gdb中執行bt指令)

Core was generated by `/tmp/prog'.
Program terminated with signal 11, Segmentation fault.
#0  manmade_crash([email protected]=0x8fdf50) at /mnt/d/workspace/crash/main.cpp:250
250                    *i = 12;
#0 xxx1.cpp:123
#1 xxx2.cpp:86
#2 xxx.h:66
Backtrace stopped: frame did not save the PC

問題找到了。

可能我們會在mips_gdb的時候看到不能載入共享庫檔案的提示

warning: Could not load shared library symbols for 9 libraries, e.g. /lib/libpthread.so.0.

From        To          Syms Read   Shared Object Library
                        No          /lib/libpthread.so.0
                        No          /usr/lib/libstdc++.so.6
                        No          /lib/libm.so.0
                        No          /lib/libgcc_s.so.1
                        No          /lib/libc.so.0
                        No          /lib/ld-uClibc.so.0

在本機使用者目錄下我們新建一個.gdbinit檔案把我們程式用到的交叉編譯鏈的庫路徑包涵進去：

set solib-search-path ~/sdk/staging_dir/toolchain-mipsel/lib