本文简要介绍了酷睿文件和gdb调试酷睿文件的方法
概述：
1 .酷睿文件
2 .设置核心程序崩溃时生成文件
3 .可以重命名核心文件
生成核心文件时
5. gdb调试核心文件
a ) gdb -c [可执行程序]
b ) gdb命令：后台/Bt
c ) gdb命令： up/down/frame
d ) gdb命令： info locals
e ) gdb命令： info args
f ) gdb命令： print/print *
1 .酷睿文件
在linux/unix上，可执行文件崩溃时会生成核心文件。 core文件是一个内存映像，调试器可以使用它来确定程序崩溃的原因。
2 .设置核心程序崩溃时生成文件
在linux/unix上，limit -a可以确定系统是否为可编程崩溃生成了核心文件。 其中，core file size是指生成的core文件的大小。 以下是在freebsd系统上输出limit -a输出的行，其中unlimited表示没有限制，如果unlimited为1024，则core文件最多生成1024个块，每个块大小最多生成512字节。 如果为0，则不生成核心文件。 酷睿文件化(512 -区块，-c )统一
酷睿文件化(512 -区块，-c ) 1024
酷睿文件化(512 -区块，-c ) 0
可以使用limit命令更改设置。 ulimit -c unlimited和limit -c 1024等。
3 .可以重命名核心文件
core文件在程序的工作目录中生成，在系统名称不同的freebsd下，默认命名为程序名称. core，该名称可以更改。 在freebsd中，可以通过man core获知，可以在sysctl中查看和修改core文件名的规则。 以下内容意味着core文件名的结构为程序名. core。
root @ FreeBSD :/# sysctl-a|grepcorefile
kern.corefile: %N.core
在freebsd中查看man core，可以了解可用于命名core文件的规则。
thenameofthefileiscontrolledviathesysctl (8)可变
kern.core file.thecontentsofthisvariabledescribesafilenameto
storethecorep _ w _ picpath to.thisfilenamecanbeabsolute，or relative
(whichwillresolvetothecurrentworkingdirectoryoftheprogramgen -
电子评级It )。
thefollowingformatspecifiersmaybeusedinthekern.corefilesysctl
toinsertadditionalinformationintotheresultingcorefilename :
% h machine主机名称。
% ianindexstartingatzerountilthesysctldebug.ncores
is reached.thiscanbeusefulforlimitingthenumber
ofcorefilesgeneratedbyaparticularprocess。
% n处理名称。
% p处理PID。
% u处理uid。
生成核心文件时
运行程序时发生致命错误，导致程序崩溃，生成核心文件。 当系统捕获信号(如SIGSEGV )时，将创建核心文件。
在man signal中，可以查看哪些信息生成core:numnamedefaultactiondescription
1 sighupterminateprocessterminallinehangup
2 sigintterminateprocessinterruptprogram
3 SIGQUIT cr
eate core p_w_picpath quit program4 SIGILL create core p_w_picpath illegal instruction
5 SIGTRAP create core p_w_picpath trace trap
6 SIGABRT create core p_w_picpath abort program (formerly SIGIOT)
7 SIGEMT create core p_w_picpath emulate instruction executed
8 SIGFPE create core p_w_picpath floating-point exception
9 SIGKILL terminate process kill program
10 SIGBUS create core p_w_picpath bus error
11 SIGSEGV create core p_w_picpath segmentation violation
12 SIGSYS create core p_w_picpath non-existent system call invoked
最常见的程序崩溃的原因便是 SIGSEGV(非法访问内存)。
5. gdb调试core文件
1) 程序在编码时，加上 -g 选项来增加调试信息。
2) 用gdb对core文件进行调试，查看程序运行状态。
下面列举一些常用的命令：
a) gdb -c [可执行程序]
运行gdb，调度core文件。如下面是我的可执行程序所在的目录：
root@freebsd:~/test/core_statck # ls
core_stack core_stack.core core_stack.cpp
core_stack.cpp 源文件
core_stack 由源文件编译出来的可执行程序
core_stack.core core_stack产生的core文件
输入命令后，gdb就会运行并输出很多信息，这些信息基本上是加载库的信息。最后还会输出最后一个stack中的信息。此时gdb是处于第0栈状态。root@freebsd:~/test/core_statck # gdb -c core_stack.core core_stack
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 `core_stack'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libc++.so.1...done.
Loaded symbols for /usr/lib/libc++.so.1
Reading symbols from /lib/libcxxrt.so.1...done.
Loaded symbols for /lib/libcxxrt.so.1
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x2829a467 in kill () from /lib/libc.so.7
(gdb)
b) gdb命令：backtrace / bt
gdb命令 bt 可以输出程序崩溃前栈上的信息，主要是程序的调用栈。(gdb) bt
#0 0x2829a467 in kill () from /lib/libc.so.7
#1 0x2829a3f7 in raise () from /lib/libc.so.7
#2 0x28298b06 in abort () from /lib/libc.so.7
#3 0x282797f8 in __assert () from /lib/libc.so.7
#4 0x08049de0 in MyDump::print (this=0xbfbfecd8, x=4, core=false) at core_stack.cpp:13
#5 0x080491bd in MyDump::detaildump (this=0xbfbfecd8, a=111, b=222) at core_stack.cpp:35
#6 0x08049166 in MyDump::dump (this=0xbfbfecd8, level=0, a=111, b=222) at core_stack.cpp:30
#7 0x08049140 in MyDump::dump (this=0xbfbfecd8, level=1, a=111, b=222) at core_stack.cpp:28
#8 0x08049140 in MyDump::dump (this=0xbfbfecd8, level=2, a=111, b=222) at core_stack.cpp:28
#9 0x08049140 in MyDump::dump (this=0xbfbfecd8, level=3, a=111, b=222) at core_stack.cpp:28
#10 0x0804928f in main () at core_stack.cpp:46
由上面输出可以看出，程序的调用情况，同时还会输出源文件中对应的行号。
c) gdb命令：up/down/frame
up: 进行上一栈
down: 进入下一栈
frame N: 进行第N栈
这三个命令主要是用户切换gdb当前所处于的栈。gdb处理某一栈的状态时，便可以通过info，print等命令来查看栈中的信息。
d) gdb命令：info locals
查看局部变量，一个很有用的命令。下面可以看到，函数内有一个局部变量lev，值为2
(gdb) info locals
lev = 2
e) gdb命令：info args
查看函数参数，一个很有用的命令。下面可以看到函数的入参有 this, level, a, b 以及它们的值。(gdb) info args
this = (MyDump *) 0xbfbfecd8
level = 2
a = 111
b = 222
f) gdb命令：print / print *
查看变量值和指针所指变量的值，一个很有用的命令。print 可以打印当前栈可见的变量，包括局部变量、函数入参、全局变量等。下面是输出this指针的对象，this所指对象有一个成员变量m_n，值为4
(gdb) print *this
$6 = {m_n = 4}
info locals, info args, print 三个命令配合起来，基本上很容易了解到程序core时的当前状态，定位core的原因。
上面的命令，大部分情况都可以定位出程序core的问题了。但是对于复杂的栈情况或是栈中有数据被破坏，这是比较能发查出的。更多的命令和用法，需要查看man gdb 和 gdb 命令 help 来了解。