在Linux 下寫線程程序的同學估計都遇到過找bug找到崩潰的情況,多線程情況下bug的追蹤實在是不容易。
現在我來介紹一個好用的方法 ulimit core。
先簡單介紹一下ulimit是個什麼(你也可以man ulimit自己查看)。
“‘當系統中的一些程序在遇到一些錯誤以及crash時,系統會自動產生core文件記錄crash時刻系統信息,包括內存和寄存器信息,用以程序員日 後debug時可以使用。這些錯誤包括段錯誤、非法指令、總線錯誤或用戶自己生成的退出信息等等,一般地,core文件在當前文件夾中存放。
但是為什麼我們平時沒有看到core文件呢? 那是因為你的系統設置了core文件的大小為0。如果你需要用core文件進行調試,用 ulimit -c unlimited即可設置core文件大小無限制。
其他參數如下:
參 數:
-a 顯示目前資源限制的設定。
-c <core文件上限> 設定core文件的最大值,單位為區塊。
-d <數據節區大小> 程序數據節區的最大值,單位為KB。
-f <文件大小> shell所能建立的最大文件,單位為區塊。
-H 設定資源的硬性限制,也就是管理員所設下的限制。
-m <內存大小> 指定可使用內存的上限,單位為KB。
-n <文件數目> 指定同一時間最多可開啟的文件數。
-p <緩沖區大小> 指定管道緩沖區的大小,單位512字節。
-s <堆疊大小> 指定堆疊的上限,單位為KB。
-S 設定資源的彈性限制。
-t <CPU時間> 指定CPU使用時間的上限,單位為秒。
-u <程序數目> 用戶最多可開啟的程序數目。
-v <虛擬內存大小> 指定可使用的虛擬內存上限,單位為KB。
你可以用ulimit -a 查看所有信息:
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 139264
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 139264
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[chenlei@yq-cl-svr2 Online_Install]$ ulimit -c 0
[chenlei@yq-cl-svr2 Online_Install]$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 139264
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 139264
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
core文件有時可能在你發生錯誤時,並沒有出現在你當前的文件夾中,發生這種情況的原因有兩個:一個是當前終端被設置為不能彈出core文件;另一種則是core文件被指定了路徑。除了可以設置core文件的大小之外,還可以對core文件的名稱進行一些規定。這種設置是對/proc/sys/kernel/core_pattern和/proc/sys/kernel/core_uses_pid這兩個文件進行修改。改動這兩個文件的方法如下:
echo <pattern> > /proc/sys/kernel/core_pattern
echo <"0"/"1"> /proc/sys/kernel/core_uses_pid
並且注意,只有超級用戶才可以修改這兩個表。’”
當你得到core文件之後,就可以利用gdb進行調試了!
gdb exe(你的可運行程序) ./core.pid(core文件)
進去後,使用bt即可查看死掉時棧的情況,省掉了無盡的調試跟蹤,是不是很方便~。
然後使用frame命令。
還有就是裡面某個線程停住,也沒死,這種情況一般就是死鎖或者涉及消息接受的超時問題(聽人說的,沒有遇到過)。遇到這種情況,可以使用:
gcore pid (調試進程的pid號)
手動生成core文件,在使用pstack(linux下好像不好使)查看堆棧的情況。如果都看不出來,就仔細查看代碼,看看是不是在 if,return,break,continue這種語句操作是忘記解鎖,還有嵌套鎖的問題,都需要分析清楚了。
有了這個方法,多線程調試再也不頭疼了!