使用truss、strace或ltrace診斷軟件的“疑難雜症”

簡介

進程無法啟動，軟件運行速度突然變慢，程序的"Segment Fault"等等都是讓每個Unix系統用戶頭痛的問題，本文通過三個實際案例演示如何使用truss、strace和ltrace這三個常用的調試工具來快速診斷軟件的"疑難雜症"。

truss和strace用來 跟蹤一個進程的系統調用或信號產生的情況，而 ltrace用來 跟蹤進程調用庫函數的情況。truss是早期為System V R4開發的調試程序，包括Aix、FreeBSD在內的大部分Unix系統都自帶了這個工具；而strace最初是為SunOS系統編寫的，ltrace最早出現在GNU/Debian Linux中。這兩個工具現在也已被移植到了大部分Unix系統中，大多數Linux發行版都自帶了strace和ltrace，而FreeBSD也可通過Ports安裝它們。

你不僅可以從命令行調試一個新開始的程序，也可以把truss、strace或ltrace綁定到一個已有的PID上來調試一個正在運行的程序。三個調試工具的基本使用方法大體相同，下面僅介紹三者共有，而且是最常用的三個命令行參數：

-f ：除了跟蹤當前進程外，還跟蹤其子進程。
-o file ：將輸出信息寫到文件file中，而不是顯示到標准錯誤輸出（stderr）。
-p pid ：綁定到一個由pid對應的正在運行的進程。此參數常用來調試後台進程。

使用上述三個參數基本上就可以完成大多數調試任務了，下面舉幾個命令行例子：

truss -o ls.truss ls -al： 跟蹤ls -al的運行，將輸出信息寫到文件/tmp/ls.truss中。
strace -f -o vim.strace vim： 跟蹤vim及其子進程的運行，將輸出信息寫到文件vim.strace。
ltrace -p 234： 跟蹤一個pid為234的已經在運行的進程。

三個調試工具的輸出結果格式也很相似，以strace為例：

1. brk(0)=0x8062aa8
2. brk(0x8063000)=0x8063000
3. mmap2(NULL,4096, PROT_READ, MAP_PRIVATE,3,0x92f)=0x40016000

每一行都是一條系統調用，等號左邊是系統調用的函數名及其參數，右邊是該調用的返回值。 truss、strace和ltrace的工作原理大同小異，都是使用ptrace系統調用跟蹤調試運行中的進程，詳細原理不在本文討論范圍內，有興趣可以參考它們的源代碼。

下面舉兩個實例演示如何利用這三個調試工具診斷軟件的"疑難雜症"：

案例一：運行clint出現Segment Fault錯誤

操作系統：FreeBSD-5.2.1-release

clint是一個C++靜態源代碼分析工具，通過Ports安裝好之後，運行：

1. # clint foo.cpp
2. Segmentation fault (core dumped)

在Unix系統中遇見"Segmentation Fault"就像在MS Windows中彈出"非法操作"對話框一樣令人討厭。OK，我們用truss給clint"把把脈"：

1. # truss -f -o clint.truss clint
2. Segmentation fault (core dumped)
3. # tail clint.truss
4. 739: read(0x6,0x806f000,0x1000)=4096(0x1000)
5. 739: fstat(6,0xbfbfe4d0)=0(0x0)
6. 739: fcntl(0x6,0x3,0x0)=4(0x4)
7. 739: fcntl(0x6,0x4,0x0)=0(0x0)
8. 739: close(6)=0(0x0)
9. 739: stat("/root/.clint/plugins",0xbfbfe680) ERR#2 'No such file or directory'
10. SIGNAL 11
11. SIGNAL 11
12. Process stopped because of:16
13. process exit, rval =139

我們用truss跟蹤clint的系統調用執行情況，並把結果輸出到文件clint.truss，然後用tail查看最後幾行。

注意看clint執行的最後一條系統調用（倒數第五行）： stat("/root/.clint/plugins",0xbfbfe680) ERR#2 'No such file or directory'，問題就出在這裡：clint找不到目錄"/root/.clint/plugins"，從而引發了段錯誤。怎樣解決？很簡單： mkdir -p /root/.clint/plugins，不過這次運行clint還是會"Segmentation Fault"9。繼續用truss跟蹤，發現clint還需要這個目錄"/root/.clint/plugins/python"，建好這個目錄後clint終於能夠正常運行了。

案例二：vim啟動速度明顯變慢

操作系統：FreeBSD-5.2.1-release

vim版本為6.2.154，從命令行運行vim後，要等待近半分鐘才能進入編輯界面，而且沒有任何錯誤輸出。仔細檢查了.vimrc和所有的vim腳本都沒有錯誤配置，在網上也找不到類似問題的解決辦法，難不成要hacking source code？沒有必要，用truss就能找到問題所在：

1. # truss -f -D -o vim.truss vim

這裡-D參數的作用是：在每行輸出前加上相對時間戳，即每執行一條系統調用所耗費的時間。我們只要關注哪些系統調用耗費的時間比較長就可以了，用less仔細查看輸出文件vim.truss，很快就找到了疑點：

1. 735:0.000021511 socket(0x2,0x1,0x0)=4(0x4)
2. 735:0.000014248 setsockopt(0x4,0x6,0x1,0xbfbfe3c8,0x4)=0(0x0)
3. 735:0.000013688 setsockopt(0x4,0xffff,0x8,0xbfbfe2ec,0x4)=0(0x0)
4. 735:0.000203657 connect(0x4,{ AF_INET 10.57.18.27:6000},16) ERR#61 'Connection refused'
5. 735:0.000017042 close(4)=0(0x0)
6. 735:1.009366553 nanosleep(0xbfbfe468,0xbfbfe460)=0(0x0)
7. 735:0.000019556 socket(0x2,0x1,0x0)=4(0x4)
8. 735:0.000013409 setsockopt(0x4,0x6,0x1,0xbfbfe3c8,0x4)=0(0x0)
9. 735:0.000013130 setsockopt(0x4,0xffff,0x8,0xbfbfe2ec,0x4)=0(0x0)
10. 735:0.000272102 connect(0x4,{ AF_INET 10.57.18.27:6000},16) ERR#61 'Connection refused'
11. 735:0.000015924 close(4)=0(0x0)
12. 735:1.009338338 nanosleep(0xbfbfe468,0xbfbfe460)=0(0x0)

vim試圖連接10.57.18.27這台主機的6000端口（第四行的connect（）），連接失敗後，睡眠一秒鐘繼續重試（第6行的nanosleep（））。以上片斷循環出現了十幾次，每次都要耗費一秒多鐘的時間，這就是vim明顯變慢的原因。

可是，你肯定會納悶："vim怎麼會無緣無故連接其它計算機的6000端口呢？"。問得好，那麼請你回想一下6000是什麼服務的端口？沒錯，就是X Server。看來vim是要把輸出定向到一個遠程X Server，那麼Shell中肯定定義了DISPLAY變量，查看.cshrc，果然有這麼一行： setenv DISPLAY ${REMOTEHOST}:0，把它注釋掉，再重新登錄，問題就解決了。

更多詳情見請繼續閱讀下一頁的精彩內容： http://www.linuxidc.com/Linux/2014-09/106664p2.htm