原文標題:Linux ?core文件 | 分享一種你可能不知道的bug定位方法
大家好,我是雜燴君。
嵌入式Linux開發(fā)中,使用gdb對core文件進行調(diào)試是一種有效的定位程序崩潰的方法。這種方法我們在之前的文章中也有簡單提過:嵌入式段錯誤的3種調(diào)試方法匯總!
有些知識,在沒用到之前,可以簡單地進行了解。實際用的時候,再去詳細地學習。最近我在實際工作中使用了gdb對core文件進行調(diào)試,遇到了一些問題,總結出來分享給大家。
本文我們來分享幾點:
什么是core文件?
前臺進程如何生成core文件?
后臺進程如何生成core文件?
如何調(diào)試core文件?
崩潰棧有用信息有限的可能原因?
什么是core文件?
在Linux下,一個程序崩潰時,它一般會在指定目錄下生成一個core文件。core文件僅僅是一個內(nèi)存映象(同時加上調(diào)試信息),主要是用來調(diào)試的。
前臺進程如何生成core文件?
實際中,我們的程序可以運行于前臺,也可以運行于后臺。前、后臺運行程序,生成core文件的方法有些不同。
前臺進程:一般而言,用戶在shell中使用./執(zhí)行的程序都是前臺程序,前臺程序可由用戶自己控制,程序運行過程中可與用戶進行交互,其運行優(yōu)先級相比后臺程序稍高,前臺程序運行過程中用戶可使用ctrl+c來終止。
core文件配置基本命令:
ulimit?-c???#?查看core文件是否打開
ulimit?-a???#?也可以查看core文件是否打開
ulimit?-c?0?#?禁止產(chǎn)生core文件
ulimit?-c?unlimited??#設置core文件大小為不限制大小
ulimit?-c?1024???#限制產(chǎn)生的core文件的大小不能超過1024KB
core文件的轉(zhuǎn)儲文件目錄和命名規(guī)則是可以設置的。
通過配置/proc/sys/kernel/core_uses_pid可以控制產(chǎn)生的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
參數(shù)%e、%p、%t表示的意思如:
%p?-?insert?pid?into?filename?添加pid
%u?-?insert?current?uid?into?filename?添加當前uid
%g?-?insert?current?gid?into?filename?添加當前gid
%s?-?insert?signal?that?caused?the?coredump?into?the?filename?添加導致產(chǎn)生core的信號
%t?-?insert?UNIX?time?that?the?coredump?occurred?into?filename?添加core文件生成時的unix時間
%h?-?insert?hostname?where?the?coredump?happened?into?filename?添加主機名
%e?-?insert?coredumping?executable?name?into?filename?添加可執(zhí)行程序名
下面開始進行實操:
查看core文件是否有打開,并設置core文件大小為不限制大?。?/p>
設置格式化的core文件保存位置或文件名:
測試代碼:
#include?<stdio.h>
int?main(int?argc,?char?**argv)
{
????printf("==================segmentation?fault?test==================n");
????int?*p?=?NULL;
????*p?=?1234;
????return?0;
}
運行測試程序生成core文件:
后臺進程如何生成core文件?
后臺程序生成core文件的方式與前臺程序不一樣。這我也是前幾天才知道的,我們設備上的程序設置為開機自啟動運行于后臺,程序崩潰時,竟然沒有生成core文件。后來查了些資料才知道后臺程序打開core文件的方式不同。
后臺進程:后臺進程又叫守護進程,是運行在系統(tǒng)后臺的一種特殊進程,它獨立于控制終端并且周期性地執(zhí)行某種任務或等待處理某些發(fā)生的事件,后臺進程最大的特點就是不受終端控制。一般用作系統(tǒng)服務,比如日志管理進程rsyslogd,數(shù)據(jù)庫服務myspld等,當然也有一些用戶程序因需要被放在后臺運行,一般被放在/etc/ini.d/文件夾中設置開機自啟動。
ulimit命令是有作用范圍的,ulimit限制的是當前shell進程以及其派生的子進程,所以通過ulimit修改coresize只是針對在當前shell下啟動的子進程,而不能影響其他shell下啟動的進程。
所以當我們配置完成生成core dump的參數(shù)后,在當前shell直接執(zhí)行的進程發(fā)生崩潰時可以正常生成core,而后臺開機自啟動的程序則無法生成,而實際總,嵌入式應用程序一般都是開機自啟動的,并且發(fā)送崩潰的時機也是不可預測的,那么使用這種方式就不能正確的去捕捉coredump文件了。
后臺進程要生成core dump文件需在進程代碼中開啟core dump功能,如:
//?公眾號:嵌入式大雜燴
#include?<stdio.h>
#include?<stdlib.h>
#include?<sys/time.h>
#include?<sys/resource.h>
#define?SHELL_CMD_CONF_CORE_FILE????"echo?/var/core-%e-%p-%t?>?/proc/sys/kernel/core_pattern"
#define?SHELL_CMD_DEL_CORE_FILE?????"rm?-f?/var/core*"
static?int?enable_core_dump(void)
{
????int?ret?=?-1;
????int?resource?=?RLIMIT_CORE;
????struct?rlimit?rlim;
????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("setrlimit?error!n");
????????return?-1;
????}
????else
????{
????????system(SHELL_CMD_CONF_CORE_FILE);
????????printf("SHELL_CMD_CONF_CORE_FILEn");
????????return?0;
????}
????return?ret;
}
int?main(int?argc,?char?**argv)
{
????enable_core_dump();
????printf("==================segmentation?fault?test==================n");
????int?*p?=?NULL;
????*p?=?1234;
????return?0;
}
讓程序開機運行于后臺:
在開發(fā)板/etc/init.d/目錄下新建文件S100Test:
#!/bin/sh
cd?/home
./test
重啟設備,程序運行崩潰時可生成core文件:
調(diào)試core文件?
把core文件傳到pc端,使用arm-linux-gnueabihf-gdb對test程序進行調(diào)試:
arm-linux-gnueabihf-gdb?test
core-file?core-test-190-119
崩潰棧信息有限?
這個demo比較簡單,可以很快定位到問題。實際中,我們的程序會依賴很多動態(tài)庫,這時候在調(diào)試時需要設置庫的搜索路徑。
這些庫需要和板子上的庫對應上,最好是用板子里的庫??梢园寻遄永镉玫降膸旆诺絇C上的某個路徑,假如放到/home/LinuxZn/lib這個路徑。
我們進入gdb時,可以輸入如下命令設置及查看庫信息:
set?solib-search-path?/home/LinuxZn/lib
info?sharedlibrary
有時候,加載庫信息之后,還是看不到有意義的崩潰棧。
有如下兩點需要確認:
- 應用程序在編譯時沒有指定-g選項,導致可執(zhí)行程序沒有調(diào)試信息。板子里的libc庫和交叉編譯器所使用的libc庫版本不一致。
如果不一致,可以把交叉編譯器所使用的libc庫更新到板子里。
參考:
https://baijiahao.baidu.com/s?id=1661025717994426637&wfr=spider&for=pc
https://blog.csdn.net/lhl_blog/article/details/106542754
以上就是本次的分享,期待你的三連!