Linux 后臺開發常用除錯工具

01 總覽

編譯階段

• nm 獲取二進制檔案包含的符號資訊
• strings 獲取二進制檔案包含的字串常量
• strip 去除二進制檔案包含的符號
• readelf 顯示目標檔案詳細資訊
• objdump 盡可能反匯編出源代碼
• addr2line 根據地址查找代碼行

運行階段

• gdb 強大的除錯工具
• ldd 顯示程式需要使用的動態庫和實際使用的動態庫
• strace 跟蹤程式當前的系統呼叫
• ltrace 跟蹤程式當前的庫函式
• time 查看程式執行時間、用戶態時間、內核態時間
• gprof 顯示用戶態各函式執行時間
• valgrind 檢查記憶體錯誤
• mtrace 檢查記憶體錯誤

其他

• proc檔案系統
• 系統日志

02 編譯階段

nm（獲取二進制檔案里面包含的符號）

符號：函式、變數

引數：

• -C 把C++函式簽名轉為可讀形式
• -A 列出符號名的時候同時顯示來自于哪個檔案，
• -a 列出所有符號（這將會把除錯符號也列出來，默認狀態下除錯符號不會被列出）
• -l 列出符號在源代碼中對應的行號（指定這個引數后，nm將利用除錯資訊找出檔案名以及符號的行號，對于一個已定義符號，將會找出這個符號定義的行號，對于未定義符號,顯示為空）
• -n 根據符號的地址來排序（默認是按符號名稱的字母順序排序的）
• -u 只列出未定義符號

strings（獲取二進制檔案里面的字串常量）

功能：

獲取二進制檔案里面的字串常量

用途：

比較重要的是檢查KEY泄露

eg：strings | grep '^.\{16\}$' 查找<your_proc>中是否存在一行有16個字符的行，并顯示出來，

選項：

• -a 不只是掃描目標檔案初始化和裝載段, 而是掃描整個檔案，
• -f 在顯示字串之前先顯示檔案名，
• -n min-len列印至少min-len字符長的字串.默認的是4，

#strings /lib/tls/libc.so.6 | grep GLIBCGLIBC_2.0GLIBC_2.1GLIBC_2.1.1……

這樣就能看到glibc支持的版本，

strip（去除二進制檔案里面包含的符號）

用途：

可執行程式減肥（通常只在已經除錯和測驗過的生成模塊上，因為不能除錯了）

反編譯、反跟蹤

readelf（顯示目標檔案詳細資訊）

nm 程式可用于列舉符號及其型別和值，但是，要更仔細地研究目標檔案中這些命名段的內容，需要使用功能更強大的工具，其中兩種功能強大的工具是objdump和readelf，

readelf工具使用來顯示一個或多個ELF格式檔案資訊的GNU工具，使用不同的引數可以查看ELF檔案不同的的資訊，

readelf  

• -a 顯示所有ELF檔案的資訊
• -h 顯示ELF檔案的檔案頭
• -l 顯示程式頭（program-header）和程式段（segment）和段下面的節
• -S 顯示較為詳細的節資訊（section）
• -s 顯示符號資訊，
• -n 顯示標識資訊（如果有）
• -r 顯示重定位資訊(如果有)
• -u 顯示展開函式資訊（如果有）
• -d 顯示動態節資訊，一般是動態庫的資訊

objdump（盡可能反匯編出源代碼）objdump –S

盡可能反匯編出源代碼，尤其當編譯的時候指定了-g引數時，效果比較明顯，

addr2line（根據地址查找代碼行）

當某個行程崩潰時，日志檔案（/var/log/messages）中就會給出附加的資訊，包括程式終止原因、故障地址，以及包含程式狀態字（PSW）、通用暫存器和訪問暫存器的簡要暫存器轉儲，

eg：Mar 31 11:34:28 l02 kernel: failing address: 0

如果可執行檔案包括除錯符號（帶-g編譯的），使用addr2line，可以確定哪一行代碼導致了問題，

eg：addr2line –e exe addr

其實gdb也有這個功能，不過addr2line的好處是，很多時候，bug很難重現，我們手上只有一份crash log，這樣就可以利用addr2line找到對應的代碼行，很方便，

注意：

1. 該可執行程式用-g編譯，使之帶除錯資訊，
2. 如果crash在一個so里面，那addr2line不能直接給出代碼行，

引數：

• -a 在顯示函式名或檔案行號前顯示地址
• -b 指定二進制檔案格式
• -C 決議C++符號為用戶級的名稱,可指定決議樣式
• -e 指定二進制檔案
• -f 同時顯示函式名稱
• -s 僅顯示檔案的基本名，而不是完整路徑
• -i 展開行內函式
• -j 讀取相對于指定節的偏移而不是絕對地址
• -p 每個位置都在一行顯示

03 運行階段

除錯程式的常見步驟：

1、確定運行時間主要花在用戶態還是內核態（比較土的一個方法：程式暫時屏蔽daemon()呼叫，hardcode收到n個請求后exit(0)，time一下程式……），

2、如果是用戶態，則使用gprof進行性能分析，

3、如果是內核態，則使用strace進行性能分析，另外可以使用其他工具（比如ltrace等）輔助，

ldd（顯示程式需要使用的動態庫和實際使用的動態庫）

# ldd /bin/lslinux-gate.so.1 =>  (0xbfffe000)librt.so.1 => /lib/librt.so.1 (0xb7f0a000)libacl.so.1 => /lib/libacl.so.1 (0xb7f04000)libc.so.6 => /lib/libc.so.6 (0xb7dc3000)libpthread.so.0 => /lib/libpthread.so.0 (0xb7dab000)/lib/ld-linux.so.2 (0xb7f1d000)libattr.so.1 => /lib/libattr.so.1 (0xb7da6000)

第一欄：需要用什么庫；第二欄：實際用哪個庫檔案；第三欄：庫檔案裝載地址，

如果缺少動態庫，就會沒有第二欄，

strace（跟蹤當前系統呼叫）

結果默認輸出到2，

• -p `` attach到一個行程
• -c 最后統計各個system call的呼叫情況
• -T 列印system call的呼叫時間
• -t/-tt/-ttt 時間格式
• -f/-F 跟蹤由fork/vfork呼叫所產生的子行程
• -o ``，將strace的輸出定向到file中，

如：strace -f -o ~/

• -e expr 指定一個運算式，用來控制如何跟蹤，格式如下:
• -e open等價于-e trace=open，表示只跟蹤open呼叫

使用 strace –e open ./prg 來看程式使用了哪些組態檔或日志檔案，很方便，

• -e trace=`` 只跟蹤指定的系統呼叫

例如：-e trace=open,close,rean,write 表示只跟蹤這四個系統呼叫.

• -e trace=file只跟蹤有關檔案操作的系統呼叫
• -e trace=process只跟蹤有關行程控制的系統呼叫
• -e trace=network跟蹤與網路有關的所有系統呼叫
• -e strace=signal 跟蹤所有與系統信號有關的系統呼叫
• -e trace=ipc跟蹤所有與行程通訊有關的系統呼叫

ltrace（跟蹤當前庫函式）

引數和strace很接近

time（查看程式執行時間、用戶態時間、內核態時間）

# time ps aux | grep 'hi'1020 21804 0.0 0.0 1888 664 pts/6 S+ 17:46 0:00 grep hireal 0m0.009suser 0m0.000ssys 0m0.004s

注意：

time只跟蹤父行程，所以不能fork

gprof（顯示用戶態各函式執行時間）

gprof原理：

在編譯和鏈接程式的時候（使用 -pg 編譯和鏈接選項），gcc在你應用程式的每個函式中都加入了一個名為mcount（or“_mcount”, or“__mcount”）的函式，也就是說-pg編譯的應用程式里的每一個函式都會呼叫mcount, 而mcount會在記憶體中保存一張函式呼叫圖，并通過函式呼叫堆疊的形式查找子函式和父函式的地址，這張呼叫圖也保存了所有與函式相關的呼叫時間，呼叫次數等等的所有資訊，

使用步驟：

1、使用 -pg 編譯和鏈接應用程式

gcc -pg -o exec exec.c

如果需要庫函式呼叫情況：

gcc -lc_p -gp -o exec exec.c

2、執行應用程式使之生成供gprof 分析的資料gmon.out

3、使用gprof 程式分析應用程式生成的資料

gprof exec gmon.out > profile.txt

注意：

程式必須通過正常途徑退出（exit()、main回傳），kill無效，對后臺常駐程式的除錯——我的比較土方法是，屏蔽daemon()呼叫，程式hardcode收到n個請求后exit(0)，

有時不太準，

只管了用戶態時間消耗，沒有管內核態消耗，

gdb core exec （gdb查看core檔案） 準備生成core：

啟動程式前，ulimit -c unlimited，設定core檔案不限制大小，（相反，ulimit -c 0，可以阻止生成core檔案）

默認在可執行程式的路徑，生成的是名字為core的檔案，新的core會覆寫舊的，

設定core檔案名字：

/proc/sys/kernel/core_uses_pid 可以控制產生的core檔案的檔案名中是否添加pid作為擴展，1為擴展，否則為0，

proc/sys/kernel/core_pattern 可以設定格式化的core檔案保存位置或檔案名，比如原來檔案內容是core，可以修改為：

echo "/data/core/core-%e-%p-%t" > core_pattern

以下是引數串列:

• %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 添加導致產生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 添加命令名

使用gdb查看core：

gdb  

opprofile （查看CPU耗在哪）

常用命令

使用oprofile進行cpu使用情況檢測，需要經過初始化、啟動檢測、匯出檢測資料、查看檢測結果等步驟，以下為常用的oprofile命令，

初始化

• opcontrol --no-vmlinux : 指示oprofile啟動檢測后，不記錄內核模塊、內核代碼相關統計資料
• opcontrol --init : 加載oprofile模塊、oprofile驅動程式

檢測控制

• opcontrol --start : 指示oprofile啟動檢測
• opcontrol --dump : 指示將oprofile檢測到的資料寫入檔案
• opcontrol --reset : 清空之前檢測的資料記錄
• opcontrol -h : 關閉oprofile行程

查看檢測結果

• opreport : 以鏡像(image)的角度顯示檢測結果，行程、動態庫、內核模塊屬于鏡像范疇
• opreport -l : 以函式的角度顯示檢測結果
• opreport -l test : 以函式的角度，針對test行程顯示檢測結果
• opannotate -s test : 以代碼的角度，針對test行程顯示檢測結果
• opannotate -s /lib64/libc-2.4.so : 以代碼的角度，針對libc-2.4.so庫顯示檢測結果

linux # opreportCPU: Core 2, speed 2128.07 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000CPU_CLK_UNHALT.........|   samples |           %| ------------------------   31645719     87.6453      no-vmlinux       4361113     10.3592      libend.so       7683      0.1367      libpython2.4.so.1.0        7046      0.1253      op_test

valgrind（檢查記憶體錯誤）

使用步驟：

1、官網下載并安裝valgrind，

2、-g編譯的程式都可以使用，

官網的示例代碼test.c

#include <stdlib.h>void f(void){  int* x = malloc(10 * sizeof(int));  x[10] = 0;        // problem 1: heap block overrun}                    // problem 2: memory leak -- x not freedint main(void){  f();  return 0;}

編譯程式gcc -Wall -g -o test test.c

3、valgrind啟動程式，螢屏輸出結果，

valgrind --tool=memcheck --leak-check=full ./test

注意：

valgrind只能查找堆記憶體的訪問錯誤，對堆疊上的物件和靜態物件沒辦法，

valgrind會影響行程性能，據說可能慢20倍，所以在性能要求高的情況下，只能使用mtrace這種輕量級的工具了（但是mtrace只能識別簡單的記憶體錯誤），

如果程式生成的core的堆疊是錯亂的，那么基本上是stackoverflow了，這種情況，可以通過在編譯的時候，加上 –fstack-protector-all 和 -D_FORTIFY_SOURCE=2 來檢測，Stack-protector-all 會在每個函式里加上堆疊保護的代碼，并在堆疊上留上指紋，（記錄下，沒用過）

因為valgrind 查不了堆疊和靜態物件的記憶體訪問越界，這類問題，可以通過使用gcc的-fmudflap –lmudflap 來檢測，（記錄下，沒用過）

全域變數的型別不一致的問題，現在還找到比較好的方法，這從另一個方面說明全域物件不是個好的設計，這給除錯帶來了麻煩，

mtrace（檢查記憶體錯誤）

mtrace是glibc內提供的工具，原理很簡單，就是把你程式中malloc()和free()的位置全部下來，最后兩輛配對，沒有配對到的就是memory leak，

使用的步驟如下：

1、代碼中添加mtrace()

#include <stdio.h>#include <stdlib.h>int main(void){  int *p;  int i;#ifdef DEBUG  setenv("MALLOC_TRACE", "./memleak.log", 1);  mtrace();#endif  p=(int *)malloc(1000);  return 0;}

這段代碼malloc了一個空間，卻沒有free掉，我們添加9-12行的mtrace呼叫，

2、編譯gcc -g -DDEBUG -o test1 test1.c

3、執行./test1，在目錄里會發現./memleak.log，

4、使用mtrace memleak.log 查看資訊，

# mtrace test1 memleak.log- 0x0804a008 Free 3 was never alloc'd 0xb7e31cbe- 0x0804a100 Free 4 was never alloc'd 0xb7ec3e3f- 0x0804a120 Free 5 was never alloc'd 0xb7ec3e47Memory not freed:-----------------Address     Size     Caller0x0804a4a8    0x3e8  at /home/illidanliu/test1.c:14

可以看到test1.c沒有對應的free()，

04 其他

proc檔案系統

內核的視窗，

proc檔案系統是一個偽檔案系統，它存在記憶體當中，而不占用外存空間，

用戶和應用程式可以通過proc得到系統的資訊，并可以改變內核的某些引數，

proc/目錄結構（部分）：

• cmdline 內核命令列
• cpuinfo 關于Cpu資訊
• devices 可以用到的設備（塊設備/字符設備）
• filesystems 支持的檔案系統
• interrupts 中斷的使用
• ioports I/O埠的使用
• kcore 內核核心映像
• kmsg 內核訊息
• meminfo　　　　 記憶體資訊
• mounts 加載的檔案系統
• stat 全面統計狀態表
• swaps 對換空間的利用情況
• version 內核版本
• uptime 系統正常運行時間
• net 網路資訊
• sys 可寫，可以通過它來訪問或修改內核的引數

proc//目錄結構（部分）：

• cmdline 命令列引數
• environ 環境變數值
• fd 一個包含所有檔案描述符的目錄
• mem 行程的記憶體被利用情況
• stat 行程狀態
• status Process status in human readable form
• cwd 當前作業目錄的鏈接
• exe Link to the executable of this process
• maps 記憶體映像
• statm 行程記憶體狀態資訊
• root 鏈接此行程的root目錄

系統日志

/var/log/下的日志檔案：

• /var/log/messages 整體系統資訊，其中也包含系統啟動期間的日志，此外，mail、cron、daemon、kern和auth等內容也記錄在var/log/messages日志中，
• /var/log/auth.log 系統授權資訊，包括用戶登錄和使用的權限機制等，
• /var/log/boot.log 系統啟動時的日志，
• /var/log/daemon.log 各種系統后臺守護行程日志資訊，
• /var/log/lastlog 記錄所有用戶的最近資訊，這不是一個ASCII檔案，因此需要用lastlog命令查看內容，
• /var/log/user.log 記錄所有等級用戶資訊的日志，
• /var/log/cron 每當cron行程開始一個作業時，就會將相關資訊記錄在這個檔案中，
• /var/log/wtmp或utmp 登錄資訊，
• /var/log/faillog 用戶登錄失敗資訊，此外，錯誤登錄命令也會記錄在本檔案中，

以上就是良許教程網為各位朋友分享Linux 后臺開發常用除錯工具，

本文由博客一文多發平臺 OpenWrite 發布！

標籤：其他

上一篇：DBA知道這17條Linux命令

下一篇：在MySQL 中使用 UTF-8