学步园

在linux中应用程序运行奔溃之后一般会产生core文件，core文件是core dump来产生，core dump又叫核心转储, 当程序运行过程中发生异常, 程序异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中。

要生成core dump文件，首先要在系统中设置core文件大小的上限，超过这个上限的core文件就不生成了，而一般系统的设置是0，即不生成core文件，所以要先修改这个上限值，设置如下：

1. 系统设置

使用ulimit -a命令查看系统所有限制情况，

使用ulimit -c ***来设置core文件大小的上限。一般使用ulimit -c unlimited即不限制core文件大小。

2. 编译程序

当然另外一个就是要是用gdb来调试程序，那编译的时候加入-g参数就是必不可少的，

下面是我在调试一个线程程序时的情况：

3. 使用gdb+core调试：

启动调试可以使用where或者bt（breaktrace）来查看错误发生的位置和堆栈。

在gdb的调试中还可以使用一下的一些命令来辅助调试：

search  fun_name 查找函数

b fun_name在这个函数处设置断点

b file.c 114 在file.c这个文件的114行设置断点

info break或者info b来查看当前设置断点的情况

run 运行程序

file 加载二进制文件

n执行下一语句

s单步执行

c继续运行

p name 打印变量

q退出

上述代码例子没有给出，下面 从这里转载个代码

http://topic.csdn.net/u/20091028/23/b5a8884a-778f-4535-8779-ae6453ada88e.html

$ more foo.c

#include  

static void sub(void);

int main(void)
{
  sub();
  return 0;
}

static void sub(void)
{
  int *p = NULL;

  /* derefernce a null pointer, expect core dump. */
  printf("%d", *p);
}

$ gcc -Wall -g foo.c
$ ./a.out
Segmentation fault

$ ls -l core.*
ls: core.*: No such file or directory

今天有人问起这个问题，于是写了个简单的例子，演示一下这个过程。FreeBSD的开发者手册上对此有专节论述，此外也可以参考gdb手册。
编写一个小程序：
CODE:

1   void foo(void)
2   {
3       *(int *)0 = 1;
4   }
5  
6   int main(void)
7   {
8       foo();
9   }
命名为foo.c，使用-g选项编译它，以便能够在core文件中包含调试信息，方便gdb跟踪至源代码行：
CODE:

gcc -g foo.c
生成的文件名就是默认的a.out。
运行这个a.out程序，显然，它会在第三行处产生一个core dump，生成a.out.core文件。
我们这时就可以使用下述命令对其进行分析：
CODE:

gdb a.out a.out.core
运行结果如下：
CODE:

[~]$gdb a.out a.out.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `a.out'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  foo () at foo.c:3
3           *(int *)0 = 1;
(gdb)
我们可以看到，这时gdb已经打印出了程序崩溃原因，以及出错的代码行位置。
如果我们想查看出问题之前的调用栈，可以使用gdb的bt命令：
CODE:

(gdb) bt
#0  foo () at foo.c:3
#1  0x080484bd in main () at foo.c:8
(gdb)
我们还可以使用up和down命令在调用栈中移动，并检查相应栈内的变量值，以便分析（复杂）程序出错的真实原因。
http://bbs.chinaunix.net/viewthread.php?tid=753996&extra=page%3D1