Ⅰ 如何察看core文件的内容
一般步骤1.filecore文件，可以显示出core文件是哪个进程产生的2.使用gdb或者dbx加载core文件，gdb进程名core文件3.where,显示堆栈信息，显示出coremp的地方例如有个程序叫ABC，产生了一个叫core的core文件，那么输入filecore,会显示这个core文件是由ABC产生的，然后输入gdbABCcore装截core文件，然后输入where显示堆栈信息
Ⅱ 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
[root@AUTOTEST_SIM2 mam2cm]#
就可以利用命令gdb进行查找，参数一是应用程序的名称，参数二是core文件，运行
gdb
cmm_test_tool core.19344结果如下:
[root@AUTOTEST_SIM2 mam2cm]# gdb cmm_test_tool core.19344
GNU 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 are
welcome 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.0
Reading symbols from
/lib/i686/libm.so.6…done.
Loaded symbols for /lib/i686/libm.so.6
Reading
symbols from /usr/lib/libz.so.1…done.
Loaded symbols for
/usr/lib/libz.so.1
Reading symbols from
/usr/lib/libstdc++.so.5…done.
Loaded symbols for
/usr/lib/libstdc++.so.5
Reading symbols from
/lib/i686/libc.so.6…done.
Loaded symbols for /lib/i686/libc.so.6
Reading
symbols from /lib/libgcc_s.so.1…done.
Loaded symbols for
/lib/libgcc_s.so.1
Reading symbols from /lib/ld-linux.so.2…done.
Loaded
symbols for /lib/ld-linux.so.2
Reading 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.so.6
#2 0×0804b4da in GetMaxIDFromDB (get_type=2,
max_id=0×806fd20) at cmm_test_tool.c:788
#3 0×0804b9d7 in ConstrctVODProgram
(vod_program=0×40345bdc) at cmm_test_tool.c:946
#4 0×0804a2f4 in
TVRequestThread (arg=0×0) at cmm_test_tool.c:372
#5 0×40021941 in
pthread_start_thread () from /lib/i686/libpthread.so.0
(gdb)
至此，可以看出文件出错的位置是函数 GetMaxIDFromDB
，两个参数分别是2和0×806fd20，这个函数位于源代码的788行，基于此，我们就可以有针对性的找到问题的根源，并加以解决。
Ⅲ gdb怎么查看程序是在哪行代码那里执行了exit退出
gdb 查看 core 文件
基本上
core 文件就是一个包含了程序崩溃时这个进程的所有信息的文件。在那 “遥远的黄金年代”，程序员不得不把 core 文件以十六进制的方式显示
出来，然后满头大汗的阅读机器码的手册，但是现在事情就简单得多了。顺便说一下， 在 FreeBSD 和其他的 4.4BSD 系统下，core 文件都叫作
progname.core 而不是简单叫 core，这样可以很清楚的表示出这个 core
文件是属于哪个 程序。
1. 要检查一个 core 文件，首先用 gdb 可执行文件名
来调试产生core文件的可执行程序：
2. 命令 core会分析 可执行程序名.core
文件
注：如果当前不是 core 文件所在目录，首先要执行 dir
/可执行程序名.core的路径/。
(gdb)core 可执行程序名.core
举例：
$gdb a.out
GDB is free software and you are
welcome to 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. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free
Software Foundation, Inc.
(gdb)core
a.out.core
Core was generated by `a.out'.
Program terminated with
signal 11, Segmentation fault.
Cannot access memory at address
0x7020796d.
#0 0x164a in bazz (anint=0x5) at temp.c:17
(gdb)
这种情况下，运行的程序叫 a.out，因此 core 文件 就叫
a.out.core。我们知道程序崩溃的原因就是函数 bazz 试图访问一块不属于它的内存。
有时候，能知道一个函数是怎么被调用的是非常有用处的。因为在一个复杂的程序里面问题可能会发生在函数调用栈上面很远的地方。
3.
命令 bt 会让 gdb
输出函数调用栈的回溯追踪
(gdb)bt
#0 0x164a in bazz (anint=0x5) at temp.c:17
#1 0xefbfd888 in end ()
#2 0x162c in main () at temp.c:11
(gdb)
函数 end() 在一个程序崩溃的时候将被调用；
在本例
中，函数 bazz()
是从 main()中被调用的。
Ⅳ 如何查看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 显示堆栈信息
Ⅳ 怎样用GDB调试core文件
一般这种情况都是因为数组越界访问，空指针或是野指针读写造成的。程序小的话还比较好办，对着源代码仔细检查就能解决。但是对于代码量较大的程序，里边包含N多函数调用，N多数组指针访问，这时想定位问题就不是很容易了（此时牛人依然可以通过在适当位置打printf加二分查找的方式迅速定位:P）。懒人的话还是直接GDB搞起吧。 神马是Core Dump文件偶尔就能听见某程序员同学抱怨“擦，又出Core了！”。简单来说，core mp说的是操作系统执行的一个动作，当某个进程因为一些原因意外终止（crash）的时候，操作系统会将这个进程当时的内存信息转储（mp）到磁盘上1。产生的文件就是core文件了，一般会以core.xxx形式命名。 如何产生Core Dump 发生doremp一般都是在进程收到某个信号的时候，Linux上现在大概有60多个信号，可以使用 kill -l 命令全部列出来。sagi@sagi-laptop:~$ kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX针对特定的信号，应用程序可以写对应的信号处理函数。如果不指定，则采取默认的处理方式, 默认处理是coremp的信号如下：3)SIGQUIT 4)SIGILL 6)SIGABRT 8)SIGFPE 11)SIGSEGV 7)SIGBUS 31)SIGSYS 5)SIGTRAP 24)SIGXCPU 25)SIGXFSZ 29)SIGIOT 我们看到SIGSEGV在其中，一般数组越界或是访问空指针都会产生这个信号。另外虽然默认是这样的，但是你也可以写自己的信号处理函数改变默认行为，更多信号相关可以看参考链接33。 上述内容只是产生coremp的必要条件，而非充分条件。要产生core文件还依赖于程序运行的shell，可以通过ulimit -a命令查看，输出内容大致如下：sagi@sagi-laptop:~$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheling priority (-e) 20 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited 看到第一行了吧，core file size，这个值用来限制产生的core文件大小，超过这个值就不会保存了。我这里输出是0，也就是不会保存core文件，即使产生了，也保存不下来==! 要改变这个设置，可以使用ulimit -c unlimited。 OK, 现在万事具备，只缺一个能产生Core的程序了，介个对C程序员来说太容易了。#include ; #include ; int crash() { char *xxx = "crash!!"; xxx[1] = 'D'; // 写只读存储区! return 2; } int foo() { return crash(); } int main() { return foo(); } 上手调试 上边的程序编译的时候有一点需要注意，需要带上参数-g, 这样生成的可执行程序中会带上足够的调试信息。编译运行之后你就应该能看见期待已久的“Segment Fault(core mped)”或是“段错误 (核心已转储)”之类的字眼了。看看当前目录下是不是有个core或是core.xxx的文件。祭出linux下经典的调试器GDB，首先带着core文件载入程序：gdb exefile core，这里需要注意的这个core文件必须是exefile产生的，否则符号表会对不上。载入之后大概是这个样子的：sagi@sagi-laptop:~$ gdb coremp core Core was generated by ./coremp'. Program terminated with signal 11, Segmentation fault. #0 0x080483a7 in crash () at coremp.c:8 8 xxx[1] = 'D'; (gdb)我们看到已经能直接定位到出core的地方了，在第8行写了一个只读的内存区域导致触发Segment Fault信号。在载入core的时候有个小技巧，如果你事先不知道这个core文件是由哪个程序产生的，你可以先随便找个代替一下，比如/usr/bin/w就是不错的选择。比如我们采用这种方法载入上边产生的core，gdb会有类似的输出：sagi@sagi-laptop:~$ gdb /usr/bin/w core Core was generated by ./coremp'. Program terminated with signal 11, Segmentation fault. #0 0x080483a7 in ? () (gdb)可以看到GDB已经提示你了，这个core是由哪个程序产生的。 GDB 常用操作 上边的程序比较简单，不需要另外的操作就能直接找到问题所在。现实却不是这样的，常常需要进行单步跟踪，设置断点之类的操作才能顺利定位问题。下边列出了GDB一些常用的操作。 启动程序：run
设置断点：b 行号|函数名
删除断点：delete 断点编号
禁用断点：disable 断点编号
启用断点：enable 断点编号
单步跟踪：next 也可以简写 n
单步跟踪：step 也可以简写 s
打印变量：print 变量名字
设置变量：set var=value
查看变量类型：ptype var
顺序执行到结束：cont
顺序执行到某一行： util lineno打印堆栈信息：bt