linux下线程调试 ulimit core

在linux 下写线程程序的同学预计都遇到过找bug找到崩溃的情况。多线程情况下bug的追踪实在是不easy。

如今我来介绍一个好用的方法 ulimit core。

先简介一下ulimit是个什么（你也能够man ulimit自己查看）。

“‘当系统中的一些程序在遇到一些错误以及crash时，系统会自己主动产生core文件记录crash时刻系统信息。包含内存和寄存器信息，用以程序猿日 后debug时能够使用。这些错误包含段错误、非法指令、总线错误或用户自己生成的退出信息等等。一般地。core文件在当前目录中存放。

可是为什么我们平时没有看到core文件呢？ 那是由于你的系统设置了core文件的大小为0。假设你须要用core文件进行调试。用 ulimit -c unlimited就可以设置core文件大小无限制。

其它參数例如以下：

<span style="font-size:18px;">參　　数：
   -a 　显示眼下资源限制的设定。

-c <core文件上限> 　设定core文件的最大值。单位为区块。

-d <数据节区大小> 　程序数据节区的最大值。单位为KB。
   -f <文件大小> 　shell所能建立的最大文件，单位为区块。
   -H 　设定资源的硬性限制，也就是管理员所设下的限制。
   -m <内存大小> 　指定可使用内存的上限，单位为KB。
   -n <文件数目> 　指定同一时间最多可开启的文件数。
   -p <缓冲区大小> 　指定管道缓冲区的大小，单位512字节。
   -s <堆叠大小> 　指定堆叠的上限，单位为KB。
   -S 　设定资源的弹性限制。

-t <CPU时间> 　指定CPU使用时间的上限，单位为秒。

-u <程序数目> 　用户最多可开启的程序数目。

-v <虚拟内存大小> 　指定可使用的虚拟内存上限，单位为KB。</span>

你能够用ulimit -a 查看全部信息：

<span style="font-size:18px;">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
</span>

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这样的语句操作是忘记解锁。还有嵌套锁的问题，都须要分析清楚了。

有了这种方法，多线程调试再也不头疼了！

參考http://www.cnblogs.com/qq78292959/archive/2012/05/08/2490443.html