Linux下C程序常常会因为内存访问错误等原因造成segment fault(段错误),此时如果系统core dump功能是打开的,那么将会有内存映像转储到硬盘上来,之后可以用gdb对core文件进行分析,还原系统发生段错误时刻的堆栈情况。这对于我们发现程序bug很有帮助。
core文件仅仅是一个内存映像(同时加上调试信息),主要是用来调试的。遇到某些无法处理的信号时会产生core文件。
使用ulimit -a可以查看系统core文件的大小限制;
使用ulimit -c [kbytes]可以设置系统允许生成的core文件大小,例如:
- ulimit -c 0 //不产生core文件
- ulimit -c 100 //设置core文件最大为100k
- ulimit -c unlimited //不限制core文件大小
先看一段造成段错误的程序,如下所示。
- #include <stdio.h>
- int main()
- {
- char *ptr = "hello world";
- *ptr = 0;
- return 0;
- }
编译后,运行结果如下所示。
此时并没有产生core文件,接下来使用ulimit -c设置core文件大小为无限制,再执行./test程序,结果如下所示。
可见core文件已经生成,接下来可以用gdb进行分析,查看堆栈情况了。
从上述输出可以清楚的看到,段错误出现在test.c的第6行,问题已经清晰地定位到了。
另外,也可以这样进行打开core文件,如下所示。
很多系统默认的core文件大小都是0,我们可以通过在shell的启动脚本/etc/bashrc等来加入ulimit -c命令来指定core文件大小,从而确保core文件能够生成。
除此之外,还可以在/proc/sys/kernel/core-pattern里设置core文件的文件名模板,详情请看core的官方man手册。
问题:
我们在运行程序的时候经常会碰到段错无 segment fault 的错误,这时候我们需要用gdb ,然后用core-file 把生成的core.*** 文件进行分析。
但今天发现一个很奇怪的现象,就是在生产的所有 core.*** 大小都是0字节。
[root@qljt pf]# ulimit -c
unlimited
所以应该不是ulimited 的问题。
问题所在:
我跑得程序(生成core.*** 的程序)并不是在linux的目录下,而是在windows 的某个分区下(该分区是通过 vmtool "/mnt/hgfs/***" 和linux 共享),导致
生成的core.*** 都是0 字节大小。
解决问题:
把需要运行的程序拷贝到linux 的根目录下运行,生成的core.*** 马上正常。
原文:http://blog.chinaunix.net/uid-26548237-id-3954090.html