什么是coredump
Coredump叫做核心转储,它是进程运行时在突然崩溃的那一刻的一个内存快照。操作系统在程序发生异常而异常在进程内部又没有被捕获的情况下,会把进程此刻内存、寄存器状态、运行堆栈等信息转储保存在一个文件里。
该文件也是二进制文件,可以使用gdb、elfdump、objdump或者windows下的windebug、solaris下的mdb进行打开分析里面的具体内容。
注:core是在半导体作为内存材料前的线圈,当时用线圈当做内存材料,线圈叫做core。用线圈做的内存叫做core memory。
ulimit
虽然我们知道进程在coredump的时候会产生core文件,但是有时候却发现进程虽然core了,但是我们却找不到core文件。
在Linux和Solaris下是需要进行设置的。
ulimit -c 可以设置core文件的大小,如果这个值为0.则不会产生core文件,这个值太小,则core文件也不会产生,因为core文件一般都比较大。
使用ulimit -c unlimited来设置无限大,则任意情况下都会产生core文件。
可以通过修改/etc/profile文件:来永久设置文件大小和文件名和存储位,在文件末尾添加:
ulimit -c unlimited
echo /data/coredump/core.%e.%p> /proc/sys/kernel/core_pattern
同时我们也可以通过ulimit修改栈区的size大小.默认是8M,当程序比较大时,就容易出现段错误.可以将其设置为200M
ulimit -a
[root@localhost driver-app]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 14991
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65535
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) 65535
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[root@localhost driver-app]#
ulimit -c unlimited
设置好了,如下所示
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
编译程序代码里,需要加上选项
CFLAGS += -D_DEBUG -O0 -g -DDEBUG=1 -Wl,
#启动调试
其中 driver-app是应用程序 ,后面6000是参数
gdb --args ./driver-app 6000
file ./driver-app
run
#调试已经产生的dump文件
gdb driver-app core.5616
bt
[root@localhost driver-app]# gdb driver-app core.59292
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-119.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/wwwroot/driver/driver-app/driver-app...done.
[New LWP 59292]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
Core was generated by `./driver-app 6000'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f9cc567d34a in __memcpy_ssse3_back () from /usr/lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-46.el7.x86_64 libcom_err-1.42.9-17.el7.x86_64 libevent-2.0.21-4.el7.x86_64 libgcc-4.8.5-39.el7.x86_64 libselinux-2.5-15.el7.x86_64 libstdc++-4.8.5-39.el7.x86_64 openssl-libs-1.0.2k-19.el7.x86_64 pcre-8.32-17.el7.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) bt
#0 0x00007f9cc567d34a in __memcpy_ssse3_back () from /usr/lib64/libc.so.6
#1 0x000000000040b5ce in on_decoder_driver_face_upload (sockfd=5, messageHeader=0x22002f0, messageBody=0x2200630 "", outBuffer=0x7ffc60e54240 "")
at ./driverdecoder.c:49
#2 0x000000000040dee1 in on_message_service (fd=5, read_buf=0x7ffc60c54240 "~\270\001\020\"\001\071\022\064Vx", read_cnt=17436, outBuffer=0x7ffc60e54240 "")
at ./main.c:398
#3 0x000000000040d35f in on_recv_cb (fd=5, events=1, arg=0x2200010) at ./main.c:139
#4 0x000000000040ae90 in ntyreactor_run (reactor=0x2200010) at ./reactor.c:268
#5 0x000000000040e118 in main (argc=2, argv=0x7ffc60e57818) at ./main.c:464
(gdb)
1、查看哪个二进制文件生成core文件,及其生成时间
#file core core.*
2、加载core文件
#gdb [exec file] [core file]
3、查看堆栈信息
(gdb)bt<n> n代表查看n层堆栈信息,可选
4、打印当前函数的参数及其值
(gdb)info args
5、查看线程信息
(gdb)info threads
6、打印所有变量的值
(gdb)info locals
7、打印当前函数的异常处理信息
(gdb)info catch
8、查看当前栈层的信息
(gdb)info f
⑴ 向上移动n层,不加n,默认一层
(gdb)up
⑵ 向下移动n层,不加n,默认一层
(gdb)down
9、附加进程
#gdb attach [进程号]
10、退出gdb
(gdb)quit