1. 如何查看core文件
在Unix系统下，应用程序崩溃，一般会产生core文件，如何根据core文件查找问题的所在，并做相应的分析和调试，是非常重要的，本文对此做简单介绍。例如，一个程序cmm_test_tool在运行的时候发生了错误，并生成了一个core文件，如下:-rw-r–r– 1 root cmm_test_tool.c-rw-r–r– 1 root cmm_test_tool.o-rwxr-xr-x 1 root cmm_test_tool-rw— 1 root core.19344-rw— 1 root core.19351-rw-r–r– 1 root cmm_test_tool.cfg-rw-r–r– 1 root cmm_test_tool.res-rw-r–r– 1 root cmm_test_tool.log[[email protected]_SIM2 mam2cm]#就可以利用命令gdb进行查找，参数一是应用程序的名称，参数二是core文件，运行gdb cmm_test_tool core.19344结果如下:[[email protected]_SIM2 mam2cm]# gdb cmm_test_tool core.19344GNU gdb Red Hat linux (5.2.1-4)Copyright 2002 Free Software Foundation, Inc.GDB is free software, covered by the GNU General Public License, and you arewelcome to change it and/or distribute copies of it under certain conditions.Type “show ing” to see the conditions.There is absolutely no warranty for GDB. Type “show warranty” for details.This GDB was configured as “i386-redhat-linux”…Core was generated by `./cmm_test_tool’.Program terminated with signal 11, Segmentation fault.Reading symbols from /lib/i686/libpthread.so.0…done.Loaded symbols for /lib/i686/libpthread.so.0Reading symbols from /lib/i686/libm.so.6…done.Loaded symbols for /lib/i686/libm.so.6Reading symbols from /usr/lib/libz.so.1…done.Loaded symbols for /usr/lib/libz.so.1Reading symbols from /usr/lib/libstdc++.so.5…done.Loaded symbols for /usr/lib/libstdc++.so.5Reading symbols from /lib/i686/libc.so.6…done.Loaded symbols for /lib/i686/libc.so.6Reading symbols from /lib/libgcc_s.so.1…done.Loaded symbols for /lib/libgcc_s.so.1Reading symbols from /lib/ld-linux.so.2…done.Loaded symbols for /lib/ld-linux.so.2Reading symbols from /lib/libnss_files.so.2…done.Loaded symbols for /lib/libnss_files.so.2#0 0×4202cec1 in __strtoul_internal () from /lib/i686/libc.so.6(gdb)进入gdb提示符，输入where，找到错误发生的位置和堆栈，如下:(gdb) where#0 0×4202cec1 in __strtoul_internal () from /lib/i686/libc.so.6#1 0×4202d4e7 in strtoul () from /lib/i686/libc.s
2. 如何查看core文件是哪个进程的
一般步骤1. file core文件，可以显示出core文件是哪个进程产生的2.使用gdb或者dbx加载专core文件， gdb 进程名 core文件3.where,显示堆栈信息，显示出属coremp的地方例如有个程序叫 ABC，产生了一个叫core的core文件，那么输入 file core, 会显示 这个core文件是由ABC产生的，然后输入 gdb ABC core装截core文件，然后 输入 where 显示堆栈信息
3. 如何察看core文件的内容
一般步骤1.filecore文件，可以显示出core文件是哪个进程产生的2.使用gdb或者dbx加载core文件，gdb进程名core文件3.where,显示堆栈信息，显示出coremp的地方例如有个程序叫ABC，产生了一个叫core的core文件，那么输入filecore,会显示这个core文件是由ABC产生的，然后输入gdbABCcore装截core文件，然后输入where显示堆栈信息
4. 如何读取core 文件内容
从接触unix开始就一直听到和遇到core mp，特别是刚学着使用C语言在AIX下编写程序的时候，core mp更是时不时就会不请自来。记得当时刚写应用的时候，提交程序时最怕的就是在运行过程时遇到core mp，对于银行核心系统，特别是使用静态应用进程，如果一个相对频繁一点的交易导致core mp，那么毫无疑问，除了赶紧定位错误改程序外，重启进程甚至无法争取到多少缓冲的时间来进行代码的更正和测试。而且往往导致core mp的，就是程序中一个小小的未注意到或者未测试到的一个疏忽。虽然常常遇到core mp，不过很长时间内，都是出于知道这个名字，知道它导致的后果，知道一部分导致它出现的原因，其他的就都不甚了了了。说起来，就是自己太懒了，懒得看书……少壮不努力啊。看过一则统计，说60岁以上的老人，超过70%都后悔少壮不努力，不知统计的数据能否反映整个社会的情况。不过总的来说，这句古话还是有些道理的。大家不要学我。哈哈core mp，翻译过来讲，就是核心转储。大致上就是指，如果由于应用错误，如浮点异常、指令异常等，操作系统将会转入内核的异常处理，向对应的进程发送特定的信号（SIGNAL），如果进程中没有对这些信号进行处理，就会转入默认的处理，core mp就是其中的一种。如果进程core mp，系统将会终止该进程，同时系统会产生core文件，以供调试使用。这个core文件其实就是内存的映像，即进程执行的时候内存的内容，也就是所谓的core mp。平常大家说某某进程core mp了，其实主要的意思就是说：某某进程因为错误而被系统自动终止了。AIX上提供了dbx工具可以对core mp进行调试，协助定位引起core mp的代码。最普通的语法是：dbx 应用名 core文件， 然后使用where命令来显示调试信息一般来讲，根据工作中遇到的情况，dbx还是能够比较轻松的根据提示的内容来定位代码的。不过也有一些特殊情况时，dbx显示的调试信息过于模糊或者不直观，这个时候就只能根据经验来逐步定位了。有时定位起来会耗用相当长的时间。遇到这种情况时，使用日志文件，通过在代码中穿插多个写log的语句，也可以协助发现。因为进程core mp时，日志当然也中断了，根据日志在哪个代码行之后或之前中止了，可以有效缩小寻找的范围。甚至，在有些情况下，使用日志定位是唯一简便的方法了。
5. linux 怎么分析core文件
从接触unix开始就一直听到和遇到core mp，特别是刚学着使用C语言在AIX下编写程序的时候， mp更是时不时就会不请自来。记得当时刚写应用的时候，提交程序时最怕的就是在运行过程时遇到core mp，对于银行核心系统，特别是使用静态应用进程，如果一个相对频繁一点的交易导致core mp，那么毫无疑问，除了赶紧定位错误改程序外，重启进程甚至无法争取到多少缓冲的时间来进行代码的更正和测试。而且往往导致core mp的，就是程序中一个小小的未注意到或者未测试到的一个疏忽。虽然常常遇到core mp，不过很长时间内，都是出于知道这个名字，知道它导致的后果，知道一部分导致它出现的原因，其他的就都不甚了了了。说起来，就是自己太懒了，懒得看书……少壮不努力啊。看过一则统计，说60岁以上的老人，超过70%都后悔少壮不努力，不知统计的数据能否反映整个社会的情况。不过总的来说，这句古话还是有些道理的。大家不要学我。哈哈core mp，翻译过来讲，就是核心转储。大致上就是指，如果由于应用错误，如浮点异常、指令异常等，操作系统将会转入内核的异常处理，向对应的进程发送特定的信号（SIGNAL），如果进程中没有对这些信号进行处理，就会转入默认的处理，core mp就是其中的一种。如果进程core mp，系统将会终止该进程，同时系统会产生core文件，以供调试使用。这个core文件其实就是内存的映像，即进程执行的时候内存的内容，也就是所谓的core mp。平常大家说某某进程core mp了，其实主要的意思就是说：某某进程因为错误而被系统自动终止了。AIX上提供了dbx工具可以对core mp进行调试，协助定位引起core mp的代码。最普通的语法是：dbx 应用名 core文件， 然后使用where命令来显示调试信息一般来讲，根据工作中遇到的情况，dbx还是能够比较轻松的根据提示的内容来定位代码的。不过也有一些特殊情况时，dbx显示的调试信息过于模糊或者不直观，这个时候就只能根据经验来逐步定位了。有时定位起来会耗用相当长的时间。遇到这种情况时，使用日志文件，通过在代码中穿插多个写log的语句，也可以协助发现。因为进程core mp时，日志当然也中断了，根据日志在哪个代码行之后或之前中止了，可以有效缩小寻找的范围。甚至，在有些情况下，使用日志定位是唯一简便的方法了。
6. 怎么打开core文件
core文件是由应用程序收到系统信号后崩溃产生的，该文件中记录了程序崩溃的原因(例如收到那种信号)，调用堆栈和崩溃时的内存及变量值等等的信息。 打开core文件与编译时使用的编译器有关，但绝大多数linux程序是使用gcc编译器编译的，因此可使用对应gdb调试器打开，命令格式如下： $ gdb 应用程序文件名 core文件名 举例： $ gdb /usr/bin/gedit ~/core —— 查看由gedit崩溃产生的core文件 (gdb) bt —— 或者backtrace, 查看程序运行到当前位置之前所有的堆栈帧情况) (gdb) quit —— 退出 如果不知道core文件由哪个文件产生的，可使用file命令显示 $ file cor
7. 如何使系统可以产生core文件
这个限制是在/etc/profile里面设置的: ulimit -S -c 0 > /dev/null 2>1 有几种方法可以让系统产生core文件。第一个方法是修改/etc/profile里面的ulimit命令，如下: ulimit -S -c unlimited > /dev/null 2>1 上面的设置允许系统上的所有用户产生没有文件大小限制的core文件。 如果只需要对部分用户或组开放产生core文件的权限，需要编辑/etc/security/limits.conf文件。例如，所有在"devel"组里面的用户可以产生core文件:#@devel soft core 是core文件的最大块大小。 在/etc/security/limits.conf文件里面有配置参数的详细说明。提示，如果想通过limits.conf里面的设置来控制用户是否 可以产生core文件，需要把/etc/profile里面的ulimits设置注释掉: # No core files by default # ulimit -S -c 0 > /dev/null 2>1 如果应用是通过daemon命令来启动的，编辑/etc/init.d/functions，注释掉ulimit的设置或改变这行: ulimit -S -c 0 >/dev/null 2>1 通过上面的设置，应用程序应该可以产生core文件。如果不能产生core文件，请检查您的应用程序是否拥有正确的uid，在程序执行的时候是否有 使用setuid改变程序的uid。 在红帽企业Linux 3上面， 可以通过下面的命令允许使用setuid的应用程序产生core文件: echo 1 > /proc/sys/kernel/core_setuid_ok 另外，您也可以在应用程序中添加下面的代码来实现: prctl(PR_SET_DUMPABLE, 1); 默认情况下，core文件会创建在应用程序的工作目录下。
8. 如何生成core文件
1、先用#ulimit -a可以查看系统core文件的大小限制（第一行），core文件大小设置为0, 即没有打开core mp设置；
[cpp] view plain print?
[email protected]:~/cnnic/project/dnsx/dnsX#ulimit-a
corefilesize(blocks,-c)0
datasegsize(kbytes,-d)unlimited
schelingpriority(-e)0
filesize(blocks,-f)unlimited
pendingsignals(-i)46621
maxlockedmemory(kbytes,-l)64
maxmemorysize(kbytes,-m)unlimited
openfiles(-n)1024
pipesize(512bytes,-p)8
POSIXmessagequeues(bytes,-q)819200
real-timepriority(-r)0
stacksize(kbytes,-s)8192
cputime(seconds,-t)unlimited
maxuserprocesses(-u)46621
virtualmemory(kbytes,-v)unlimited
filelocks(-x)unlimited
[email protected]:~/cnnic/project/dnsx/dnsX# ulimit -acore file size (blocks, -c) 0data seg size (kbytes, -d) unlimitedscheling priority (-e) 0file size (blocks, -f) unlimitedpending signals (-i) 46621max locked memory (kbytes, -l) 64max memory size (kbytes, -m) unlimitedopen files (-n) 1024pipe size (512 bytes, -p) 8POSIX message queues (bytes, -q) 819200real-time priority (-r) 0stack size (kbytes, -s) 8192cpu time (seconds, -t) unlimitedmax user processes (-u) 46621virtual memory (kbytes, -v) unlimitedfile locks (-x) unlimited2、接下来使用#ulimit -c [kbytes]可以设置系统允许生成的core文件大小；
ulimit -c 0 不产生core文件
ulimit -c 100 设置core文件最大为100k
ulimit -c unlimited 不限制core文件大小
执行#ulimit -c unlimited，然后#ulimit -a查看结果如下（第一行）：
[cpp] view plain print?
[email protected]:~/cnnic/project/dnsx/dnsX#ulimit-a
corefilesize(blocks,-c)unlimited
datasegsize(kbytes,-d)unlimited
schelingpriority(-e)0
filesize(blocks,-f)unlimited
pendingsignals(-i)46621
maxlockedmemory(kbytes,-l)64
maxmemorysize(kbytes,-m)unlimited
openfiles(-n)1024
pipesize(512bytes,-p)8
POSIXmessagequeues(bytes,-q)819200
real-timepriority(-r)0
stacksize(kbytes,-s)8192
cputime(seconds,-t)unlimited
maxuserprocesses(-u)46621
virtualmemory(kbytes,-v)unlimited
filelocks(-x)unlimited
[email protected]:~/cnnic/project/dnsx/dnsX# ulimit -acore file size (blocks, -c) unlimiteddata seg size (kbytes, -d) unlimitedscheling priority (-e) 0file size (blocks, -f) unlimitedpending signals (-i) 46621max locked memory (kbytes, -l) 64max memory size (kbytes, -m) unlimitedopen files (-n) 1024pipe size (512 bytes, -p) 8POSIX message queues (bytes, -q) 819200real-time priority (-r) 0stack size (kbytes, -s) 8192cpu time (seconds, -t) unlimitedmax user processes (-u) 46621virtual memory (kbytes, -v) unlimitedfile locks (-x) unlimited此时，core mp设置打开了，再执行程序出现段错误时，在当前工作目录下产生了core文件，然后我们就可以用gdb调试core文件了。
例如：
#gdb ./test core.2065
注：Linux下的C程序常常会因为内存访问错误等原因造成segment fault(段错误)，此时如果系统core mp功能是打开的，那么将会有内存映像转储到硬盘上来，之后可以用gdb对core文件进行分析，还原系统发生段错误时刻的堆栈情况。这对于我们发现程序bug很有帮助。
很多系统默认的core文件大小都是0，我们可以通过在shell的启动脚本/etc/bashrc或者~/.bashrc等地方来加入 ulimit -c 命令来指定core文件大小，从而确保core文件能够生成。
除此之外，还可以在/proc/sys/kernel/core_pattern里设置core文件的文件名模板，详情请看core的官方man手册。
需要说明的是：上述方法只是在当前shell中生效,重启之后，就不再有效了。永久生效的办法是如下：
永久生效办法：
#vi /etc/profile 然后，在profile中添加：
ulimit -c 1073741824
(但是，若将产生的转储文件大小大于该数字时，将不会产生转储文件)
或者
ulimit -c unlimited
这样重启机器后生效了。 或者， 使用source命令使之马上生效。
#source /etc/profile
三、指定内核转储的文件名和目录
修改完内核转储设置后，当程序core mp后发现确实在本地目录产生了core文件，但是如果程序多次core mp时，core文件会被覆盖，原因是每次core mp后生成的文件名默认都叫core，接下来就分享下如果想在每次core m时产生的core文件都带上进程号怎么操作，或者你想把内核转储文件保存到其他目录怎么办？
1、core mp文件名自动加上进程ID
#echo 1 >/proc/sys/kernel/core_uses_pid
最后生成的core mp文件名会加上进程ID.
2、另外可以通过修改kernel的参数，指定内核转储所生成的core文件的路径和文件名。
可以通过在/etc/sysctl.conf文件中，对sysctl变量kernel.core_pattern的设置。
#vim /etc/sysctl.conf 然后，在sysctl.conf文件中添加下面两句话：
kernel.core_pattern = /var/core/core_%e_%p
kernel.core_uses_pid = 0
保存后退出。
注：如果/proc/sys/kernel/core_uses_pid这个文件的内容被配置成1，即使core_pattern中没有设置%p，最后生成的core mp文件名仍会加上进程ID。
这里%e, %p分别表示：
%c 转储文件的大小上限
%e 所mp的文件名
%g 所mp的进程的实际组ID
%h 主机名
%p 所mp的进程PID
%s 导致本次coremp的信号
%t 转储时刻(由1970年1月1日起计的秒数)
%u 所mp进程的实际用户ID
可以使用以下命令，使修改结果马上生效。
#sysctl –p /etc/sysctl.conf
请在/var目录下先建立core文件夹，然后执行a.out程序，就会在/var/core/下产生以指定格式命名的内核转储文件。查看转储文件的情况：
#ls /var/core
core_a.out_2456
9. linux上的core文件，麻烦牛人们帮忙解释下是什么原因
关于UNIX/Linux系统来下面产生的core文件，根据我自使用系统的经验，通常是由于自己在编写程序的过程中，由于自己的疏忽，使自己编写的程序产生了数组越界、或者是程序中的指针指向了一块无效的内存区域，产生的内存溢出错误。这一点在C语言编程过程中尤为明显，即：虽然定义了一个指针变量，但是未对该变量进行初始化、且判断该指针是否为空指针，而在后面的程序中又使用到了该变量，这时候肯定就会产生内存溢出错误。通常产生的提示信息就是：Segmentfault，CoreDumped！此时再一看自己当前工作的目录下面，就会自动产生出一个文件名为core的文件，通常该文件占得空间也是比较大的，至少好几兆字节。
