嵌入式Linux開發(fā)中,使用gdb對(duì)core文件進(jìn)行調(diào)試是一種有效的定位程序崩潰的方法。
有些知識(shí),在沒用到之前,可以簡單地進(jìn)行了解。實(shí)際用的時(shí)候,再去詳細(xì)地學(xué)習(xí)。最近我在實(shí)際工作中使用了gdb對(duì)core文件進(jìn)行調(diào)試,遇到了一些問題,總結(jié)出來分享給大家。
本文我們來分享幾點(diǎn):
什么是core文件?
前臺(tái)進(jìn)程如何生成core文件?
后臺(tái)進(jìn)程如何生成core文件?
如何調(diào)試core文件?
崩潰棧有用信息有限的可能原因?
什么是core文件?
在Linux下,一個(gè)程序崩潰時(shí),它一般會(huì)在指定目錄下生成一個(gè)core文件。core文件僅僅是一個(gè)內(nèi)存映象(同時(shí)加上調(diào)試信息),主要是用來調(diào)試的。
前臺(tái)進(jìn)程如何生成core文件?
實(shí)際中,我們的程序可以運(yùn)行于前臺(tái),也可以運(yùn)行于后臺(tái)。前、后臺(tái)運(yùn)行程序,生成core文件的方法有些不同。
前臺(tái)進(jìn)程:一般而言,用戶在shell中使用./執(zhí)行的程序都是前臺(tái)程序,前臺(tái)程序可由用戶自己控制,程序運(yùn)行過程中可與用戶進(jìn)行交互,其運(yùn)行優(yōu)先級(jí)相比后臺(tái)程序稍高,前臺(tái)程序運(yùn)行過程中用戶可使用ctrl+c來終止。
core文件配置基本命令:
ulimit-c#查看core文件是否打開 ulimit-a#也可以查看core文件是否打開 ulimit-c0#禁止產(chǎn)生core文件 ulimit-cunlimited#設(shè)置core文件大小為不限制大小 ulimit-c1024#限制產(chǎn)生的core文件的大小不能超過1024KB
core文件的轉(zhuǎn)儲(chǔ)文件目錄和命名規(guī)則是可以設(shè)置的。
通過配置/proc/sys/kernel/core_uses_pid可以控制產(chǎn)生的core文件的文件名中是否添加pid作為擴(kuò)展;
通過配置/proc/sys/kernel/core_pattern可以設(shè)置格式化的core文件保存位置或文件名。
比如:
設(shè)置core文件的文件名中是否添加pid作為擴(kuò)展
echo"1">/proc/sys/kernel/core_uses_pid
設(shè)置格式化的core文件保存位置或文件名
echo"/var/core-%e-%p-%t">/proc/sys/kernel/core_pattern
參數(shù)%e、%p、%t表示的意思如:
%p-insertpidintofilename添加pid %u-insertcurrentuidintofilename添加當(dāng)前uid %g-insertcurrentgidintofilename添加當(dāng)前gid %s-insertsignalthatcausedthecoredumpintothefilename添加導(dǎo)致產(chǎn)生core的信號(hào) %t-insertUNIXtimethatthecoredumpoccurredintofilename添加core文件生成時(shí)的unix時(shí)間 %h-inserthostnamewherethecoredumphappenedintofilename添加主機(jī)名 %e-insertcoredumpingexecutablenameintofilename添加可執(zhí)行程序名
下面開始進(jìn)行實(shí)操:
查看core文件是否有打開,并設(shè)置core文件大小為不限制大小:
設(shè)置格式化的core文件保存位置或文件名:
測試代碼:
#includeintmain(intargc,char**argv) { printf("==================segmentationfaulttest================== "); int*p=NULL; *p=1234; return0; }
運(yùn)行測試程序生成core文件:
后臺(tái)進(jìn)程如何生成core文件?
后臺(tái)程序生成core文件的方式與前臺(tái)程序不一樣。這我也是前幾天才知道的,我們設(shè)備上的程序設(shè)置為開機(jī)自啟動(dòng)運(yùn)行于后臺(tái),程序崩潰時(shí),竟然沒有生成core文件。后來查了些資料才知道后臺(tái)程序打開core文件的方式不同。
后臺(tái)進(jìn)程:后臺(tái)進(jìn)程又叫守護(hù)進(jìn)程,是運(yùn)行在系統(tǒng)后臺(tái)的一種特殊進(jìn)程,它獨(dú)立于控制終端并且周期性地執(zhí)行某種任務(wù)或等待處理某些發(fā)生的事件,后臺(tái)進(jìn)程最大的特點(diǎn)就是不受終端控制。一般用作系統(tǒng)服務(wù),比如日志管理進(jìn)程rsyslogd,數(shù)據(jù)庫服務(wù)myspld等,當(dāng)然也有一些用戶程序因需要被放在后臺(tái)運(yùn)行,一般被放在/etc/ini.d/文件夾中設(shè)置開機(jī)自啟動(dòng)。
ulimit命令是有作用范圍的,ulimit限制的是當(dāng)前shell進(jìn)程以及其派生的子進(jìn)程,所以通過ulimit修改coresize只是針對(duì)在當(dāng)前shell下啟動(dòng)的子進(jìn)程,而不能影響其他shell下啟動(dòng)的進(jìn)程。
所以當(dāng)我們配置完成生成core dump的參數(shù)后,在當(dāng)前shell直接執(zhí)行的進(jìn)程發(fā)生崩潰時(shí)可以正常生成core,而后臺(tái)開機(jī)自啟動(dòng)的程序則無法生成,而實(shí)際總,嵌入式應(yīng)用程序一般都是開機(jī)自啟動(dòng)的,并且發(fā)送崩潰的時(shí)機(jī)也是不可預(yù)測的,那么使用這種方式就不能正確的去捕捉coredump文件了。
后臺(tái)進(jìn)程要生成core dump文件需在進(jìn)程代碼中開啟core dump功能,如:
左右滑動(dòng)查看全部代碼>>>
//公眾號(hào):嵌入式大雜燴 #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; }
讓程序開機(jī)運(yùn)行于后臺(tái):
在開發(fā)板/etc/init.d/目錄下新建文件S100Test:
#!/bin/sh cd/home ./test
設(shè)置程序開機(jī)自啟動(dòng)可參考我們往期文章:《淺析程序開機(jī)自啟動(dòng)》
重啟設(shè)備,程序運(yùn)行崩潰時(shí)可生成core文件:
調(diào)試core文件?
把core文件傳到pc端,使用arm-linux-gnueabihf-gdb對(duì)test程序進(jìn)行調(diào)試:
arm-linux-gnueabihf-gdbtest core-filecore-test-190-119
![b7131498-4851-11ed-a3b6-dac502259ad0.png](https://file1.elecfans.com//web2/M00/A1/EC/wKgaomTt5dSAEe6yAAG-f8vRZEU753.png)
![b7266ab6-4851-11ed-a3b6-dac502259ad0.png](https://file1.elecfans.com//web2/M00/A1/EC/wKgaomTt5dSANDHiAAJWt6o__2g269.png)
崩潰棧信息有限?
這個(gè)demo比較簡單,可以很快定位到問題。實(shí)際中,我們的程序會(huì)依賴很多動(dòng)態(tài)庫,這時(shí)候在調(diào)試時(shí)需要設(shè)置庫的搜索路徑。
這些庫需要和板子上的庫對(duì)應(yīng)上,最好是用板子里的庫。可以把板子里用到的庫放到PC上的某個(gè)路徑,假如放到/home/LinuxZn/lib這個(gè)路徑。
我們進(jìn)入gdb時(shí),可以輸入如下命令設(shè)置及查看庫信息:
setsolib-search-path/home/LinuxZn/lib infosharedlibrary
![b7ded1dc-4851-11ed-a3b6-dac502259ad0.png](https://file1.elecfans.com//web2/M00/A1/EC/wKgaomTt5dSAcVJCAAIOKcjgiWc876.png)
有時(shí)候,加載庫信息之后,還是看不到有意義的崩潰棧。
有如下兩點(diǎn)需要確認(rèn):
應(yīng)用程序在編譯時(shí)沒有指定-g選項(xiàng),導(dǎo)致可執(zhí)行程序沒有調(diào)試信息。
板子里的libc庫和交叉編譯器所使用的libc庫版本不一致。
如果不一致,可以把交叉編譯器所使用的libc庫更新到板子里。
審核編輯:劉清
-
PID控制
+關(guān)注
關(guān)注
10文章
460瀏覽量
40302 -
Linux開發(fā)
+關(guān)注
關(guān)注
0文章
34瀏覽量
6961 -
GDB調(diào)試
+關(guān)注
關(guān)注
0文章
24瀏覽量
1492
原文標(biāo)題:分享一種你可能不知道的bug定位方法
文章出處:【微信號(hào):玩轉(zhuǎn)嵌入式,微信公眾號(hào):玩轉(zhuǎn)嵌入式】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評(píng)論請先 登錄
相關(guān)推薦
QEMU+GDB調(diào)試ARM程序
使用GDB調(diào)試Linux應(yīng)用程序
GDB調(diào)試命令總結(jié)
嵌入式Linux的GDB調(diào)試環(huán)境建立
段錯(cuò)誤調(diào)試神器 - Core Dump詳解
Linux應(yīng)用的GDB調(diào)試的原理及過程分析
![Linux應(yīng)用的<b class='flag-5'>GDB</b><b class='flag-5'>調(diào)試</b>的原理及過程分析](https://file.elecfans.com/web1/M00/B5/54/pIYBAF5gWW-ARv_SAABcEAzxVmk577.png)
實(shí)例演示GDB的使用
![實(shí)例演示<b class='flag-5'>GDB</b>的使用](https://file.elecfans.com/web1/M00/CA/38/o4YBAF-M8baAV-dwAAA2Ex6JN7w626.png)
GDB調(diào)試原理是什么?
嵌入式Linux GDB調(diào)試環(huán)境搭建與使用
![嵌入式Linux <b class='flag-5'>GDB</b><b class='flag-5'>調(diào)試</b>環(huán)境搭建與使用](https://file.elecfans.com/web1/M00/D9/4E/pIYBAF_1ac2Ac0EEAABDkS1IP1s689.png)
在ubuntu中調(diào)試GDB
![在ubuntu中<b class='flag-5'>調(diào)試</b><b class='flag-5'>GDB</b>](https://file1.elecfans.com/web2/M00/8D/FD/wKgaomTCKxCAGEqwAAAJmUuGa5Q744.jpg)
GDB調(diào)試工具的原理
![<b class='flag-5'>GDB</b><b class='flag-5'>調(diào)試</b>工具的原理](https://file1.elecfans.com/web2/M00/AD/44/wKgaomVMntmARfX1AAA0QpsI-74694.jpg)
如何使用GDB調(diào)試工具
![如何使用<b class='flag-5'>GDB</b><b class='flag-5'>調(diào)試</b>工具](https://file1.elecfans.com/web2/M00/AD/44/wKgaomVMoQ-ALIZ1AAG9PSG5F_o447.jpg)
評(píng)論