在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這種語句操作是忘記解鎖，還有嵌套鎖的問題，都需要分析清楚了。
有了這個方法，多線程調試再也不頭疼了！
