嵌入式裝置使用GDB及coredump檔案查詢崩潰問題
背景:
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個檔案,一個是帶除錯資訊的,另外一個是我們實際執行的。方法如下:
- 編譯選項加上-g生成了體積巨大的程式prog,我們備份為prog_debug,prog_debug是用來分析崩潰檔案的。
- 在交叉工具鏈中找到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.
在gdb中輸入(gdb) info sharedlibrary檢視下共享庫的載入情況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
這樣使用mips_gdb分析的時候就可以載入程式使用的共享庫了。相關推薦
嵌入式裝置使用GDB及coredump檔案查詢崩潰問題
背景:1.執行目標為MIPS機器,FLASH及RAM資源都非常緊張,無法執行帶除錯資訊的程式2.程式有一定概率崩潰,從表現上難以分析目標:直接定位到崩潰目的碼說明:1、2在執行環境中操作,3、4在編譯環境中操作1.設定核心轉儲核心轉儲可以儲存程式崩潰時的記憶體狀態。是系統級別
嵌入式裝置LCD模組漢字型檔檔案生成方式
近期有專案需要用的LCD顯示沐足顯示一些中文,對比了下帶字型檔的模組要比不帶字型檔的模組要貴得多,想想那就自己建立字型檔吧,能剩下不少費用,再說裝置內部的FLASH大把的容量,不利用也有點浪費了。 下文轉載自:http://www.rationmcu.com/elecjc/356.html
gdb除錯coredump檔案,函式名稱是問號
google key: gdb問號 今天總算解決了一個大的bug,爽! 我的程式crash,有了coredump檔案,在Linux PC上用arm-linux-gdb debug it. The result is: #0 0x4022b178 in
文字處理及檔案查詢
title: 文字處理及檔案查詢 date: 2018-10-14 18:18:18 tags: VIM Find Sed 正則表示式 shell指令碼 文字處理及正則表示式 檔案檢視 檔案檢視命令: cat,tac,re
mybatis xml檔案中的大於、小於、及like模糊查詢的寫法
在xml中,特殊符號的轉義寫法如下: < < > > <> <> & & &
linux使用者及檔案查詢許可權相關命令筆記
使用者 1.新增使用者 sudo adduser 使用者名稱 sudo useradd使用者名稱 adduser 和 useradd 的區別是什麼 useradd 只建立使用者,建立完了用 passwd lilei 去設定新使用者的密碼。adduser 會建立使用者,建立目錄,
25 驅動裝置申請及原始碼實現裝置檔案建立一體函式(miscdevice)
驅動裝置申請及原始碼實現裝置檔案建立一體函式(miscdevice) miscdevice是字元裝置驅動的簡化版本,方便實現一個簡單的字元裝置驅動。 只適用於沒有同類型的裝置驅動,也就是一個驅動只對應一個硬體。 相關變數及函式: #include <lin
wlh- beagle bone 通過uboot tftp 載入zImage 裝置樹 及 nfs 掛載根檔案系統
首先重啟Ubuntu 伺服器的 tftp 和nfs sudo /etc/init.d/xinetd restart 命令 重啟 xinetd tftp服務 sudo&nbs
gdb除錯(檢視函式棧、除錯coredump檔案)
下面有一檔案exception.c #include <stdio.h> int main() { int code = 0; scanf("%d",code); printf("%d\n",code); return 0; }編譯 gcc -g -o exceptio
linux gdb 除錯 coredump core 檔案,函式名稱是 問號
google key: gdb問號 我的程式crash,有了coredump檔案,在Linux PC上用arm-linux-gdb debug it. The result is: #0 0x4022b178 in ?? () (gdb) bt #0
windows 應用程式崩潰時的記憶體轉儲及dump檔案的分析
1、在現場設定程式崩潰時的自動記憶體轉儲,得到dump檔案 在windows 登錄檔如下項: //HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/AeDebug
嵌入式系統啟動及初始化——連結檔案Project.prm
本文出自一本北京航空航天大學出版的書籍,摘抄至此,標為轉載,僅用來學習交流。連結檔案Project.prm prm檔案主要實現了晶片的RAM和ROM的定義,初始化RAM中的變數、堆疊的大小;定義復位向量,即應用程式的預設入口;還包括了啟動程式碼,即硬體復位後的函式入口。prm
python 檔案查詢及內容匹配
需求:程式開發中有大量的介面,但在實際的使用中有一部分是沒有使用的,在開發的程式中匹配這些介面名,找到哪些介面從沒有使用過。將這些沒有使用過的介面名儲存下來。 程式碼結構: 結構解析: 1、find
用gdb分析core檔案及常見gdb命令操作示例
1.概述 在實際的軟體開發專案中,程式出現問題是在所難免的。遙想本人蔘加工作之後首次遇到程式的情景,至今還歷歷在目。之前的經驗告訴我,我們越是驚慌失措,問題就越是解決不了。我們要先讓自己平靜下來,然後再尋找解決程式問題的辦法。 在Linux下做開發的朋友,想
GDB如何從Coredump檔案恢復動態庫資訊
[原創]轉載請註明來源於CSDN _xiao。 在Linux生成Coredump檔案時程式並沒有對動態連結庫檔案資訊進行特殊處理,但GDB在載入Coredump檔案時卻能正確載入所有的動態連結庫,包括程式執行中呼叫dlopen動態載入的so檔案,其原理是什麼呢?這裡通過對G
VS2005(vs2008,vs2010)使用map檔案查詢程式崩潰原因
一般程式崩潰可以通過debug,找到程式在那一行程式碼崩潰了,最近編一個多執行緒的程式,都不知道在那發生錯誤,多執行緒併發,又不好單行除錯,終於找到一個比較好的方法來找原因,通過生成map檔案,由於2005取消map檔案生成行號資訊(vc6.0下是可以生成行號資訊的,不知
嵌入式裝置從linux機上拷檔案配nfs
ubunte配nfs伺服器1. sudo service nfs-kernel-server restart安裝2.sudo vi /etc/exports /home/tanyb/share/work/his/dirmount 192.168.30.0/255.255.25
Linux檔案查詢命令及find詳解
一、linux的檔案查詢工具 1、locate工具 2、find工具 二、locate命令 1、特點: (1)依賴資料庫(可以用update更新資料庫,但費時長,現實企業環境最好不用) (2
Sql Server查詢磁碟的可用空間,資料庫資料檔案及日誌檔案的大小及利用率
在MS Sql Server中可以能過以下的方法查詢出磁碟空間的使用情況及各資料庫資料檔案及日誌檔案的大小及使用利用率:1、查詢各個磁碟分割槽的剩餘空間: Exec master.dbo.xp_fixeddrives 2、查詢資料庫的資料檔案及日誌檔案的相關資訊(包括檔案組、當前檔案大小、檔
數據查詢,簡單查詢及高級查詢
最小 最大 sum() and 離散 沒有 民族 結果 nbsp 查詢所有列1.select * from info查特定列2.select code,name from info查出列後加別名,再查姓名3.select code as ‘代號‘,name as ‘姓名‘