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