嵌入式Linux開發中，使用gdb對core文件進行調試是一種有效的定位程序崩潰的方法。

有些知識，在沒用到之前，可以簡單地進行了解。實際用的時候，再去詳細地學習。最近我在實際工作中使用了gdb對core文件進行調試，遇到了一些問題，總結出來分享給大家。

本文我們來分享幾點：

什么是core文件？

前臺進程如何生成core文件？

后臺進程如何生成core文件？

如何調試core文件？

崩潰棧有用信息有限的可能原因？

什么是core文件？

在Linux下，一個程序崩潰時，它一般會在指定目錄下生成一個core文件。core文件僅僅是一個內存映象(同時加上調試信息)，主要是用來調試的。

前臺進程如何生成core文件？

實際中，我們的程序可以運行于前臺，也可以運行于后臺。前、后臺運行程序，生成core文件的方法有些不同。

前臺進程：一般而言，用戶在shell中使用./執行的程序都是前臺程序，前臺程序可由用戶自己控制，程序運行過程中可與用戶進行交互，其運行優先級相比后臺程序稍高，前臺程序運行過程中用戶可使用ctrl+c來終止。

core文件配置基本命令：

ulimit-c#查看core文件是否打開
ulimit-a#也可以查看core文件是否打開
ulimit-c0#禁止產生core文件
ulimit-cunlimited#設置core文件大小為不限制大小
ulimit-c1024#限制產生的core文件的大小不能超過1024KB

core文件的轉儲文件目錄和命名規則是可以設置的。

通過配置/proc/sys/kernel/core_uses_pid可以控制產生的core文件的文件名中是否添加pid作為擴展；

通過配置/proc/sys/kernel/core_pattern可以設置格式化的core文件保存位置或文件名。

比如：

設置core文件的文件名中是否添加pid作為擴展

echo"1">/proc/sys/kernel/core_uses_pid

設置格式化的core文件保存位置或文件名

echo"/var/core-%e-%p-%t">/proc/sys/kernel/core_pattern

參數%e、%p、%t表示的意思如：

%p-insertpidintofilename添加pid
%u-insertcurrentuidintofilename添加當前uid
%g-insertcurrentgidintofilename添加當前gid
%s-insertsignalthatcausedthecoredumpintothefilename添加導致產生core的信號
%t-insertUNIXtimethatthecoredumpoccurredintofilename添加core文件生成時的unix時間
%h-inserthostnamewherethecoredumphappenedintofilename添加主機名
%e-insertcoredumpingexecutablenameintofilename添加可執行程序名

下面開始進行實操：

查看core文件是否有打開，并設置core文件大小為不限制大小：

設置格式化的core文件保存位置或文件名：

測試代碼：

#include

intmain(intargc,char**argv)
{
printf("==================segmentationfaulttest==================
");

int*p=NULL;
*p=1234;

return0;
}

運行測試程序生成core文件：

后臺進程如何生成core文件？

后臺程序生成core文件的方式與前臺程序不一樣。這我也是前幾天才知道的，我們設備上的程序設置為開機自啟動運行于后臺，程序崩潰時，竟然沒有生成core文件。后來查了些資料才知道后臺程序打開core文件的方式不同。

后臺進程：后臺進程又叫守護進程，是運行在系統后臺的一種特殊進程，它獨立于控制終端并且周期性地執行某種任務或等待處理某些發生的事件，后臺進程最大的特點就是不受終端控制。一般用作系統服務，比如日志管理進程rsyslogd，數據庫服務myspld等，當然也有一些用戶程序因需要被放在后臺運行，一般被放在/etc/ini.d/文件夾中設置開機自啟動。

ulimit命令是有作用范圍的，ulimit限制的是當前shell進程以及其派生的子進程，所以通過ulimit修改coresize只是針對在當前shell下啟動的子進程，而不能影響其他shell下啟動的進程。

所以當我們配置完成生成core dump的參數后，在當前shell直接執行的進程發生崩潰時可以正常生成core，而后臺開機自啟動的程序則無法生成，而實際總，嵌入式應用程序一般都是開機自啟動的，并且發送崩潰的時機也是不可預測的，那么使用這種方式就不能正確的去捕捉coredump文件了。

后臺進程要生成core dump文件需在進程代碼中開啟core dump功能，如：

左右滑動查看全部代碼>>>

//公眾號：嵌入式大雜燴
#include
#include
#include
#include

#defineSHELL_CMD_CONF_CORE_FILE"echo/var/core-%e-%p-%t>/proc/sys/kernel/core_pattern"
#defineSHELL_CMD_DEL_CORE_FILE"rm-f/var/core*"

staticintenable_core_dump(void)
{
intret=-1;
intresource=RLIMIT_CORE;
structrlimitrlim;

rlim.rlim_cur=1?RLIM_INFINITY:0;
rlim.rlim_max=1?RLIM_INFINITY:0;

system(SHELL_CMD_DEL_CORE_FILE);

if(0!=setrlimit(resource,&rlim))
{
printf("setrlimiterror!
");
return-1;
}
else
{
system(SHELL_CMD_CONF_CORE_FILE);
printf("SHELL_CMD_CONF_CORE_FILE
");
return0;
}

returnret;
}

intmain(intargc,char**argv)
{
enable_core_dump();

printf("==================segmentationfaulttest==================
");

int*p=NULL;
*p=1234;

return0;
}

讓程序開機運行于后臺：

在開發板/etc/init.d/目錄下新建文件S100Test：

#!/bin/sh
cd/home
./test

設置程序開機自啟動可參考我們往期文章：《淺析程序開機自啟動》

重啟設備，程序運行崩潰時可生成core文件：

調試core文件？

把core文件傳到pc端，使用arm-linux-gnueabihf-gdb對test程序進行調試：

arm-linux-gnueabihf-gdbtest
core-filecore-test-190-119

崩潰棧信息有限？

這個demo比較簡單，可以很快定位到問題。實際中，我們的程序會依賴很多動態庫，這時候在調試時需要設置庫的搜索路徑。

這些庫需要和板子上的庫對應上，最好是用板子里的庫。可以把板子里用到的庫放到PC上的某個路徑，假如放到/home/LinuxZn/lib這個路徑。

我們進入gdb時，可以輸入如下命令設置及查看庫信息：

setsolib-search-path/home/LinuxZn/lib
infosharedlibrary

有時候，加載庫信息之后，還是看不到有意義的崩潰棧。

有如下兩點需要確認：

應用程序在編譯時沒有指定-g選項，導致可執行程序沒有調試信息。

板子里的libc庫和交叉編譯器所使用的libc庫版本不一致。

如果不一致，可以把交叉編譯器所使用的libc庫更新到板子里。

審核編輯：劉清