coredump简介与coredump原因总结

时间:2022-12-06 08:48:43
from:http://www.cnblogs.com/doctorqbw/archive/2011/12/21/2295962.html
 
 

coredump简介与coredump原因总结

什么是coredump?

通常情况下coredmp包含了程序运行时的内存,寄存器状态,堆栈指针,内存管理信息等。可以理解为把程序工作的当前状态存储成一个文件。许多程序和操作系统出错时会自动生成一个core文件。

如何使用coredump?

coredump可以用在很多场合,使用Linux,或者solaris的人可能都有过这种经历,系统在跑一些压力测试或者系统负载一大的话,系统就hang住了或者干脆system panic.这时唯一能帮助你分析和解决问题的就是coredump了。

现在很多应该程序出错时也会出现coredump.

分析coredump的工具

现在大部分类unix操作系统都提供了分析core文件的工具,比如 GNU Binutils Binary File Descriptor library (BFD), GNU Debugger(gdb),mdb等

coredump的文件格式

类unix操作系统中使用efi格式保存coredump文件。

在solairs下

bash-3.2# file *unix.3 ELF 32-bit LSB executable 80386 Version 1, statically linked, not stripped, no debugging information availableunix.4 ELF 32-bit LSB executable 80386 Version 1, statically linked, not stripped, no debugging information available

造成程序coredump的原因很多,这里根据以往的经验总结一下:

1 内存访问越界
  a) 由于使用错误的下标,导致数组访问越界
  b) 搜索字符串时,依靠字符串结束符来判断字符串是否结束,但是字符串没有正常的使用结束符
  c) 使用strcpy, strcat, sprintf, strcmp, strcasecmp等字符串操作函数,将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防止读写越界。
 
2 多线程程序使用了线程不安全的函数。
应该使用下面这些可重入的函数,尤其注意红色标示出来的函数,它们很容易被用错:
asctime_r(3c) gethostbyname_r(3n) getservbyname_r(3n) ctermid_r(3s) gethostent_r(3n) getservbyport_r(3n) ctime_r(3c) getlogin_r(3c) getservent_r(3n) fgetgrent_r(3c) getnetbyaddr_r(3n) getspent_r(3c) fgetpwent_r(3c) getnetbyname_r(3n) getspnam_r(3c) fgetspent_r(3c) getnetent_r(3n) gmtime_r(3c) gamma_r(3m) getnetgrent_r(3n) lgamma_r(3m) getauclassent_r(3) getprotobyname_r(3n) localtime_r(3c) getauclassnam_r(3) etprotobynumber_r(3n) nis_sperror_r(3n) getauevent_r(3) getprotoent_r(3n) rand_r(3c) getauevnam_r(3) getpwent_r(3c) readdir_r(3c) getauevnum_r(3) getpwnam_r(3c) strtok_r(3c) getgrent_r(3c) getpwuid_r(3c) tmpnam_r(3s) getgrgid_r(3c) getrpcbyname_r(3n) ttyname_r(3c) getgrnam_r(3c) getrpcbynumber_r(3n) gethostbyaddr_r(3n) getrpcent_r(3n)
 
3 多线程读写的数据未加锁保护。
对于会被多个线程同时访问的全局数据,应该注意加锁保护,否则很容易造成core dump
 
4 非法指针
  a) 使用空指针
  b) 随意使用指针转换。一个指向一段内存的指针,除非确定这段内存原先就分配为某种结构或类型,或者这种结构或类型的数组,否则不要将它转换为这种结构或类型 的指针,而应该将这段内存拷贝到一个这种结构或类型中,再访问这个结构或类型。这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的,那么访问它 时就很容易因为bus error而core dump.
 
5 堆栈溢出
不要使用大的局部变量(因为局部变量都分配在栈上),这样容易造成堆栈溢出,破坏系统的栈和堆结构,导致出现莫名其妙的错误。

coredump文件的生成方法以及使用方法:

(假设下例是在x86上交叉编译,而在arm上运行异常的现象)

1.  在arm内核里加入coredump的支持(一般内核都支持coredump, 不用重编)

2.  运行命令,此时允许coredump文件产生:(在arm上)
 ulimit –c unlimited

3.  执行程序:(在arm上)
./test
在异常退出时,会显示如下信息,注意括号里的内容
Segmentation fault (core dumped)
程序执行目录下将产生*core文件

4.  用gdb分析:(在x86上)
arm-linux-gdb ./test test.core
再用gdb的bt或where看就可以了
(arm-linux-gdb的编译见<调试工具之四gdbserve>)


系统支持生成core并设置存储位置的方法:

1> 在/etc/profile中加入以下一行,这将允许生成coredump文件
ulimit -c unlimited

2> 在rc.local中加入以下一行,这将使程序崩溃时生成的coredump文件位于/tmp目录下:
echo /tmp/core.%e.%p > /proc/sys/kernel/core_pattern  

/tmp/也可以是其它的目录位置。最佳位置应当满足以下需求:
* 对所有用户可写
* 空间容量足够大
* 掉电后文件不丢失

查看栈信息
—————

当程序被停住了,你需要做的第一件事就是查看程序是在哪里停住的。当你的程序调用了一个函数,函数的地址,函数参数,函数内的局部变量都会被压入“栈”(Stack)中。你可以用GDB命令来查看当前的栈中的信息。

下面是一些查看函数调用栈信息的GDB命令:

backtrace 
    bt 
        打印当前的函数调用栈的所有信息。如:
        
        (gdb) bt
        #0  func (n=250) at tst.c:6
        #1  0x08048524 in main (argc=1, argv=0xbffff674) at tst.c:30
        #2  0x400409ed in __libc_start_main () from /lib/libc.so.6
        
        从上可以看出函数的调用栈信息:__libc_start_main --> main() --> func()
        
    
    backtrace <n>
    bt <n> 
        n是一个正整数,表示只打印栈顶上n层的栈信息。

backtrace <-n> 
    bt <-n> 
        -n表一个负整数,表示只打印栈底下n层的栈信息。
        
如果你要查看某一层的信息,你需要在切换当前的栈,一般来说,程序停止时,最顶层的栈就是当前栈,如果你要查看栈下面层的详细信息,首先要做的是切换当前栈。

frame <n> 
    f <n> 
        n是一个从0开始的整数,是栈中的层编号。比如:frame 0,表示栈顶,frame 1,表示栈的第二层。
    
    up <n>
        表示向栈的上面移动n层,可以不打n,表示向上移动一层。 
        
    down <n> 
        表示向栈的下面移动n层,可以不打n,表示向下移动一层。

上面的命令,都会打印出移动到的栈层的信息。如果你不想让其打出信息。你可以使用这三个命令:
    
            select-frame <n> 对应于 frame 命令。
            up-silently <n> 对应于 up 命令。
            down-silently <n> 对应于 down 命令。

查看当前栈层的信息,你可以用以下GDB命令:

frame 或 f 
        会打印出这些信息:栈的层编号,当前的函数名,函数参数值,函数所在文件及行号,函数执行到的语句。
    
    info frame 
    info f 
        这个命令会打印出更为详细的当前栈层的信息,只不过,大多数都是运行时的内内地址。比如:函数地址,调用函数的地址,被调用函数的地址,目前的函数是由什么样的程序语言写成的、函数参数地址及值、局部变量的地址等等。如:
            (gdb) info f
            Stack level 0, frame at 0xbffff5d4:
             eip = 0x804845d in func (tst.c:6); saved eip 0x8048524
             called by frame at 0xbffff60c
             source language c.
             Arglist at 0xbffff5d4, args: n=250
             Locals at 0xbffff5d4, Previous frame's sp is 0x0
             Saved registers:
              ebp at 0xbffff5d4, eip at 0xbffff5d8
              
     info args
        打印出当前函数的参数名及其值。
     
     info locals
        打印出当前函数中所有局部变量及其值。
        
     info catch
        打印出当前的函数中的异常处理信息。
        
        
        
        
查看源程序
—————

显示源代码

GDB 可以打印出所调试程序的源代码,当然,在程序编译时一定要加上-g的参数,把源程序信息编译到执行文件中。不然就看不到源程序了。当程序停下来以后,GDB会报告程序停在了那个文件的第几行上。你可以用list命令来打印程序的源代码。还是来看一看查看源代码的GDB命令吧。
    
    list <linenum>
        显示程序第linenum行的周围的源程序。
    
    list <function> 
        显示函数名为function的函数的源程序。
        
    list 
        显示当前行后面的源程序。
    
    list - 
        显示当前行前面的源程序。

一般是打印当前行的上5行和下5行,如果显示函数是是上2行下8行,默认是10行,当然,你也可以定制显示的范围,使用下面命令可以设置一次显示源程序的行数。

set listsize <count>
        设置一次显示源代码的行数。
        
    show listsize
        查看当前listsize的设置。

list命令还有下面的用法:

list <first>, <last>
        显示从first行到last行之间的源代码。
    
    list , <last>
        显示从当前行到last行之间的源代码。
        
    list +
        往后显示源代码。

一般来说在list后面可以跟以下这们的参数:

<linenum>   行号。
    <+offset>   当前行号的正偏移量。
    <-offset>   当前行号的负偏移量。
    <filename:linenum>  哪个文件的哪一行。
    <function>  函数名。
    <filename:function> 哪个文件中的哪个函数。
    <*address>  程序运行时的语句在内存中的地址。

搜索源代码

不仅如此,GDB还提供了源代码搜索的命令:

forward-search <regexp> 
    search <regexp>
        向前面搜索。

reverse-search <regexp> 
        全部搜索。
        
其中,<regexp>就是正则表达式,也主一个字符串的匹配模式,关于正则表达式,我就不在这里讲了,还请各位查看相关资料。

指定源文件的路径

某些时候,用-g编译过后的执行程序中只是包括了源文件的名字,没有路径名。GDB提供了可以让你指定源文件的路径的命令,以便GDB进行搜索。

directory <dirname ... >
    dir <dirname ... >
        加一个源文件路径到当前路径的前面。如果你要指定多个路径,UNIX下你可以使用“:”,Windows下你可以使用“;”。
    directory 
        清除所有的自定义的源文件搜索路径信息。
    
    show directories 
        显示定义了的源文件搜索路径。

源代码的内存

你可以使用info line命令来查看源代码在内存中的地址。info line后面可以跟“行号”,“函数名”,“文件名:行号”,“文件名:函数名”,这个命令会打印出所指定的源码在运行时的内存地址,如:

(gdb) info line tst.c:func
        Line 5 of "tst.c" starts at address 0x8048456 <func+6> and ends at 0x804845d <func+13>.

还有一个命令(disassemble)你可以查看源程序的当前执行时的机器码,这个命令会把目前内存中的指令dump出来。如下面的示例表示查看函数func的汇编代码。

(gdb) disassemble func
        Dump of assembler code for function func:
        0x8048450 <func>:       push   %ebp
        0x8048451 <func+1>:     mov    %esp,%ebp
        0x8048453 <func+3>:     sub    $0x18,%esp
        0x8048456 <func+6>:     movl   $0x0,0xfffffffc(%ebp)
        0x804845d <func+13>:    movl   $0x1,0xfffffff8(%ebp)
        0x8048464 <func+20>:    mov    0xfffffff8(%ebp),%eax
        0x8048467 <func+23>:    cmp    0x8(%ebp),%eax
        0x804846a <func+26>:    jle    0x8048470 <func+32>
        0x804846c <func+28>:    jmp    0x8048480 <func+48>
        0x804846e <func+30>:    mov    %esi,%esi
        0x8048470 <func+32>:    mov    0xfffffff8(%ebp),%eax
        0x8048473 <func+35>:    add    %eax,0xfffffffc(%ebp)
        0x8048476 <func+38>:    incl   0xfffffff8(%ebp)
        0x8048479 <func+41>:    jmp    0x8048464 <func+20>
        0x804847b <func+43>:    nop
        0x804847c <func+44>:    lea    0x0(%esi,1),%esi
        0x8048480 <func+48>:    mov    0xfffffffc(%ebp),%edx
        0x8048483 <func+51>:    mov    %edx,%eax
        0x8048485 <func+53>:    jmp    0x8048487 <func+55>
        0x8048487 <func+55>:    mov    %ebp,%esp
        0x8048489 <func+57>:    pop    %ebp
        0x804848a <func+58>:    ret
        End of assembler dump.

部分转自:http://blog.csdn.net/haoel/article/details/2882

coredump简介与coredump原因总结的更多相关文章

  1. &lbrack;转&rsqb;coredump简介与coredump原因总结

    [转]coredump简介与coredump原因总结 http://blog.sina.com.cn/s/blog_54f82cc201013srb.html 什么是coredump? 通常情况下co ...

  2. coredump

    COREDUMP调试的使用 一,什么是coredump 跑程序的时候经常碰到SIGNAL 或者 call trace的问题,需要定位解决,这里说的大部分是指对应程序由于各种异常或者bug导致在运行过程 ...

  3. coredump调试的使用

    一,什么是coredump 跑程序的时候经常碰到SIGNAL 或者 call trace的问题,需要定位解决,这里说的大部分是指对应程序由于各种异常或者bug导致在运行过程中异常退出或者中止,并且在满 ...

  4. 嵌入式系统coredump设计

    阴沟翻船,马失前蹄,说明凡事皆有可能.自然,程序设计的再好,也会有crash的时候.开发期还还说,正式交付的系统crash自然更是难以承受的.无论何时,死一次就够了,得有方法查个水落石出. 几年前哥去 ...

  5. Doris开发手记3:利用CoreDump文件快速定位Doris的查询问题

    Apache Doris的BE部分是由C++编写,当出现一些内存越界,非法访问的问题时会导致BE进程的Crash.这部分的问题常常较难排查,同时也很难快速定位到对应的触发SQL,给使用者带来较大的困扰 ...

  6. Linux coredump

    前面写过通过注册信号处理函数定位SEGV问题.其实Linux coredump机制也是比较好的debug手段. 进程由于某种异常或者bug导致在运行过程中异常退出或者中止,有时会产生一个叫做core的 ...

  7. Linux coredump学习笔记

    初学者笔记:linux的程序在发生异常情况下,会导致进程down,多数服务器会设置生成core文件,本人在实际运营过程中发生过进程不断core,被自动监控拉起,过段时间有core的情况,进而导致磁盘被 ...

  8. gdb 调试coredump文件过程

    gdb 调试coredump文件过程: 第一步:首先需要一个进程的coredump文件,怎么搞出coredump文件呢? 1. ps -fax|grep                 进程名称 找到 ...

  9. linux下 gdb&plus;coredump 调试偶发crash的程序

    1. 打开 core dump 查看是否打开 ulimit -c 如果输出0, 说明没有打开. 方法一:使用命令 ulimit -c unlimited 可以打开,但是只对当前终端有效, 方法二: 配 ...

随机推荐

  1. 安装gitolite,并ssh公钥无密码登录

    安装gitolite,并ssh公钥无密码登录 gitolite是管理git版本库的一种方案,它将git版本库的管理信息放在了一个特殊git版本库里.gitolite与linux操作系统集成了,需要使用 ...

  2. java对cookie的操作&lowbar;01

    /** * 读取所有cookie * 注意二.从客户端读取Cookie时,包括maxAge在内的其他属性都是不可读的,也不会被提交.浏览器提交Cookie时只会提交name与value属性.maxAg ...

  3. &commat;Controller和&commat;RestController之间的区别

    1. Controller, RestController的共同点 都是用来表示Spring某个类的是否可以接收HTTP请求 2. Controller, RestController的不同点 @Co ...

  4. C&num; 30分钟完成百度人脸识别——进阶篇(文末附源码)

    距离上次入门篇时隔两个月才出这进阶篇,小编惭愧,对不住关注我的卡哇伊的小伙伴们,为此小编用这篇博来谢罪. 前面的准备工作我就不说了,注册百度账号api,创建web网站项目,引入动态链接库引入. 不了解 ...

  5. 消除游戏源码 Match 3 Jewel Full 298 Levels

    Match 3 Jewel Full 298 Levels 一款unity3d编写的消消乐游戏, 关卡丰富,很好玩 下载地址:点击下载

  6. Object&period;create&lpar;&rpar; 创建实例对象

    var person1 = { name: '张三', age: 38, greeting: function() { console.log('Hi! I\'m ' + this.name + '. ...

  7. java的PDF纵横向打印

    PDF默认是纵向打印的,通过rotate()来让其改变为横向打印,一般在打印A4 12*21纸以及发票的时候会用横向打印.横向打印时页面会出现行转列以及列转行的情况,因此在设置页面大小的时候一定要宽度 ...

  8. 最详细的springmvc-mybatis教程

    链接:http://blog.csdn.net/qq598535550/article/details/51703190

  9. 第一次ACM赛后总结及感悟

    2014 "嘉杰信息"杯 ACM/ICPC湖南程序设计邀请赛暨第六届湘潭程序设计比赛 赛后总结,尽管已经是大二第二学期了,这却是我的第一次真正的ACM比赛经历,大一尽管说就已经进了 ...

  10. bzoj1251&colon; 序列终结者 fhqtreap写法

    fhqtreap的速度果然很快 花了时间学了下指针写法 没有旋转 只有分裂以及合并操作 其实还是蛮好写的 #include<cstdio> #include<cstring> ...