在平時編碼中有時候會遺漏對指針等內存操作的異常保護，而當設備訪問異常內存空間時，操作系統會直接殺死改進程。當代碼流程較多時，排查這類問題就比較痛苦，索性linux提供了coredump，改文件會保存進程被kill前調用的棧信息，根據這些信息我們可以快速的定位故障點。本文將介紹在openwrt中如果根據coredump來快速定位程序崩潰問題。
編寫一個內存使用異常的程序：
編寫一個helloworld程序，改程序直接訪問空指針，改操作肯定會導致進程崩潰。
開啟coredump功能：
openwrt中一般默認沒有打開coredump功能，所以我們要先開啟改功能，按照下面的配置開啟之後，如果進程異常崩潰了，則會在/tmp目錄下生成coredump文件。
ulimit -c unlimited
echo "/tmp/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
執行helloworld程序：
從下圖可以看出，我們已經生成了coredump文件。
分析coredump文件：
將coredump文件提取出來放到cross_gdb工具的目錄（該工具一般都可以在網上下載到）。
因為我們沒有使用到動態庫，所以我們錯誤點肯定在helloworld下，所以我們只需要將編譯目錄中的helloword文件也拷貝到cross_gdb(注意不要直接從設備中導出該文件，因為設備中的app是去掉符號表的，你看不到什麼有效的信息)。
打開mips-linux-gnu-gdb.exe,將app文件和core文件分別載入，然後輸入bt命令就可以看到進程崩潰前的棧信息了。
導入app命令： file helloworld
導入core文件命令： core-file core-helloworld-2714-1558599983
當故障點在共享庫時如何定位：
當故障app包含多個共享庫時，我們無法確定到底是哪個共享庫出問題，可以先只加載core文件，這時候bt時無法看到具體函數名，我們可以依據該地址去跟系統中該進程的map表進行對比，進而確認到底是哪個共享庫出現異常。
如下圖所示，紅框內是進程號，我們的helloworld程序不會一直執行，所以沒辦法查看，這邊隨便找了個其他的程序作為例子。在map表中可以看到每個共享庫都有其所在的內存地址範圍，根據這個就可以確定是哪個庫出現異常了，進而可以objdump該庫查看具體的故障內容。
閱讀更多 soar0603 的文章
