结合程序崩溃后的core文件分析bug

fireway fireway     2022-08-17     450

关键词:

引言

    在《I/O的效率比较》中,我们在修改图1程序的BUF_SIZE为8388608时,运行程序出现崩溃,如下图1:
    
    图1. 段错误
    一般而言,导致程序段错误的原因如下:
  • 内存访问出错,这类问题的典型代表就是数组越界。
  • 非法内存访问,出现这类问题主要是程序试图访问内核段内存而产生的错误。
  • 栈溢出, Linux默认给一个进程分配的栈空间大小为8M,因此你的数组开得过大的话会出现这种问题。
    首先我们先看一下系统默认分配的资源:
$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 7884
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) 7884
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
    可以看到默认分配的栈大小为8M。而刚好我们的代码里的栈大小调到了8M,因此出现了段错误。
    那么有没有一种更直接明了的方法来识别和分析应用程序崩溃产生的bug呢? 有,那就是通过程序崩溃后产生的core文件。

core文件

何为core文件.

    core dump又叫内核转储, 在Unix系统中,核心映像(core image)就是“进程”执行当时的内存内容,当进程发生错误或收到“信号”而终止执行时,系统会将核心映像写入一个文件,以作为调试之用,这就是所谓的核心转储(core dump)。而core文件一般产生在进程的当前工作目录下。
    所以core文件中只是程序的内存映像, 如果在编译时加入调试信息的话,那么还会有调试信息。

如何产生core文件

    我们运行了a.out程序出现了“段错误”,但没有产生core文件。这是因为系统默认core文件的大小为0,所以没有创建。可以用ulimit命令查看和修改core文件的大小。 
$ ulimit -c 0     <--------- c选项指定修改core文件的大小
$ ulimit -c 1000   <--------指定了core文件大小为1000KB, 如果设置的大小小于core文件,则对core文件截取
$ ulimit -c unlimited   <---------------对core文件的大小不做限制
    如果想让修改永久生效,则需要修改配置文件,如.bash_profile、/etc/profile或/etc/security/limits.conf
    我们回到上面的代码演示,把core文件的大小调成不限制,再执行a.out,就可以在当前目录看到core文件了。
    
    另外补充一些资料,说明一些情况也不会产生core文件。
  1. 进程是设置-用户-ID,而且当前用户并非程序文件的所有者; 
  2. 进程是设置-组-ID,而且当前用户并非该程序文件的组所有者; 
  3. 用户没有写当前工作目录的许可权; 
  4. 文件太大。core文件的许可权(假定该文件在此之前并不存在)通常是用户读/写,组读和其他读。 

为什么需要core文件

    关于core产生的原因很多,比如过去一些Unix的版本不支持现代Linux上这种gdb直接附着到进程上进行调试的机制,需要先向进程发送终止信号,然后用工具阅读core文件。在Linux上,我们就可以使用kill向一个指定的进程发送信号或者使用gcore命令来使其主动出core并退出。
    如果从浅层次的原因上来讲,出core意味着当前进程存在BUG,需要程序员修复。
    从深层次的原因上讲,是当前进程触犯了某些OS层级的保护机制,逼迫OS向当前进程发送诸如SIGSEGV(即signal 11)之类的信号, 例如访问空指针或数组越界出core,实际上是触犯了OS的内存管理,访问了非当前进程的内存空间,OS需要通过出core来进行警示,这就好像一个人身体内存在病毒,免疫系统就会通过发热来警示,并导致人体发烧是一个道理(有意思的是,并不是每次数组越界都会出Core,这和OS的内存管理中虚拟页面分配大小和边界有关,即使不出core,也很有可能读到脏数据,引起后续程序行为紊乱,这是一种很难追查的BUG)。

core文件的名称和生成路径 

    默认情况下core的文件名叫"core"
    /proc/sys/kernel/core_uses_pid可以控制core文件的文件名中是否添加pid作为扩展
  • 文件内容为1,表示添加pid作为扩展名,生成的core文件格式为core.PID
  • 为0则表示生成的core文件统一命名为core.
    如何修改这个文件的内容?
$ echo "0" > /proc/sys/kernel/core_uses_pid
    /proc/sys/kernel/core_pattern文件用于定制core的文件名,一般使用%配合不同的字符:
  • %p  出core进程的PID
  • %u  出core进程的UID
  • %s  造成core的signal号
  • %t  出core的时间,从1970-01-0100:00:00开始的秒数
  • %e  出core进程对应的可执行文件名

如何阅读core文件

    产生了core文件之后,就是如何查看core文件,并确定问题所在,进行修复。为此,我们不妨先来看看core文件的格式,多了解一些core文件。
$ file core.4244 
core.4244: ELF 64-bit LSB  core file x86-64, version 1 (SYSV), SVR4-style, from '/home/fireway/study/temp/a.out'
    首先可以明确一点,core文件的格式ELF格式,通过使用readelf -h命令来查看更详细内容
$ readelf -h core.4244
ELF 头:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              CORE (Core 文件)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  入口点地址:               0x0
  程序头起点:          64 (bytes into file)
  Start of section headers:          0 (bytes into file)
  标志:             0x0
  本头的大小:       64 (字节)
  程序头大小:       56 (字节)
  Number of program headers:         19
  节头大小:         0 (字节)
  节头数量:         0
  字符串表索引节头: 0
    了解了这些之后,我们来看看如何阅读core文件,并从中追查BUG。在Linux下,一般读取core的命令为:
$ gdb exec_file core_file
    使用gdb,先从可执行文件中读取符号表信息,然后读取core文件。如果不与可执行文件搅合在一起可以吗?答案是不行,因为core文件中没有符号表信息,无法进行调试,可以使用如下命令来验证:
$ objdump -x core.4244 | tail
 26 load16        00001000  00007ffff7ffe000  0000000000000000  0003f000  2**12
                  CONTENTS, ALLOC, LOAD
 27 load17        00801000  00007fffff7fe000  0000000000000000  00040000  2**12
                  CONTENTS, ALLOC, LOAD
 28 load18        00001000  ffffffffff600000  0000000000000000  00841000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
SYMBOL TABLE:
no symbols    <----------------- 表明当前的ELF格式文件中没有符号表信息
    结合上面知识点,我们分别编译带-g的目标可执行mycat_debug和不带-g的目标可执行mycat,会发现mycat_debug的文件大小稍微大一些。使用readelf命令得出的结果比较报告,详细见附件-readelf报告.html
    各自执行产生的core文件,再使用objdump命令得出的结果比较报告,详细见附件-objdump报告.html
    最后我们各自使用gdb读取core文件,得出的结果比较报告,详细见附件-gdb_core报告.html
    如果我们强制使用gdb mycat, 接着是带有调试信息的core文件,gdb会有什么提示呢?
Reading symbols from mycat...(no debugging symbols found)...done.
warning: core file may not match specified executable file.
[New LWP 2037]
Core was generated by `./mycat_debug'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000400957 in main ()
    接下来重点来看,为啥产生段错误?
    使用gdb mycat_debug core.2037可见:
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from mycat_debug...done.
[New LWP 2037]
Core was generated by `./mycat_debug'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  main () at io1.c:16
16    int n = 0;
可知程序段错误,代码是int n = 0;这一句,我们来看当前栈信息:
(gdb) info f
Stack level 0, frame at 0x7ffc4b59d670:
 rip = 0x400957 in main (io1.c:16); saved rip = 0x7fc5c0d5aec5
 source language c.
 Arglist at 0x7ffc4b59d660, args: 
 Locals at 0x7ffc4b59d660, Previous frame's sp is 0x7ffc4b59d670
 Saved registers:
  rbp at 0x7ffc4b59d660, rip at 0x7ffc4b59d668
    其中可见指令指针rip指向地址为0x400957, 我们用x命令来查看内存地址中的值。具体帮助查看gdb调试 - 查看内存一节
    (gdb) x/5i 0x400957 或者x/5i $rip
=> 0x400957 <main+26>:movl   $0x0,-0x800014(%rbp)
   0x400961 <main+36>:lea    -0x800010(%rbp),%rax
   0x400968 <main+43>:mov    $0x800000,%edx
   0x40096d <main+48>:mov    $0x0,%esi
   0x400972 <main+53>:mov    %rax,%rdi
    这条movl指令要把立即数0送到-0x800014(%rbp)这个地址去,其中rbp存储的是帧指针,其地址是 0x7ffc4b59d660,而-0x800014显然是个负数,十进制是8388628,且栈空间是由高地址向低地址延伸,见图2,那么n的栈地址就是-0x800014(%rbp),也就是$rbp-8388628。当我们尝试访问此地址时


图2. 典型的存储空间安排
 
(gdb) x /b 0x7ffc4ad9d64c
0x7ffc4ad9d64c: Cannot access memory at address 0x7ffc4ad9d64c
可以看到无法访问此内存地址,这是因为它已经超过了OS允许的范围。

ulimit命令参数及用法

功能说明:控制shell程序的资源。
补充说明:ulimit为shell内建指令,可用来控制shell执行程序的资源。
参  数: 
  • -a   显示目前资源限制的设定。 
  • -c   设定core文件的最大值,单位为KB。 
  • -d    <数据节区大小> 程序数据节区的最大值,单位为KB。 
  • -f     <文件大小> shell所能建立的最大文件,单位为区块。 
  • -H  设定资源的硬性限制,也就是管理员所设下的限制。 
  • -m    <内存大小> 指定可使用内存的上限,单位为KB。
  • -n     <文件数目> 指定同一时间最多可开启的文件数。
  • -p     <缓冲区大小> 指定管道缓冲区的大小,单位512字节。
  • -s     <堆叠大小> 指定堆叠的上限,单位为KB。
  • -S  设定资源的弹性限制。 
  • -t   指定CPU使用时间的上限,单位为秒。 
  • -u    <程序数目> 用户最多可开启的程序数目。 
  • -v    <虚拟内存大小>  指定可使用的虚拟内存上限,单位为KB。

参考

 

附件列表

 

如何分析,java虚拟机异常崩溃由系统捕获并生成的core文件

该格式是个ELF的二进制文件,请问该文件应该用什么工具进行分析。当前用visualvm,jac,ha,mat均无法分析。请问改用什么工具分析。该core文件应该类似C语言出现段错误被系统捕获生成的core文件参考技术Ayyyyffwert 查看详情

linux程序崩溃分析(代码片段)

引言我们在做Linux开发时,常常会遇到程序崩溃的问题,这时会用gdb或者通过查看反汇编的方式去对程序进行分析,接下来,我们从底层的角度,去讲述如何分析程序崩溃的原因。一、常见BUG在进行分析前࿰... 查看详情

gdbcore文件进到某行

...只需要让pCtrStr指针指向具体的地址即可。此时仔细分析程序,发现pCtrStr指针为空。当对一个不存在的指针取长度时,由于找不到地址,程序便崩溃了。所以让pCtrStr指针指向具体的地址就可以了。什么是coredump,大部分是指对应... 查看详情

go--通过gotraceback生成程序崩溃后core文件的方法(gcoregdb)

写一个错误的c程序 packagedlsymimport"testing"funcTest_intercept(t*testing.T){Intercept("gethostbynamex00")}packagedlsym//#cgoCFLAGS:-I.//#include<stddef.h>//#include"dlsym_wrapper.h"import"C"impor 查看详情

分析树脂负载测试生成的 .core 文件

...试。有没有其他工具可以使用?【问题讨论】:GDB可以在崩溃后加载核心文件,您不必在GDB中运行程 查看详情

通过 lldb 从 Linux(ARM32、Debian、RaspberryPi3B+)分析 .NET Core 控制台应用程序崩溃转储失败

...b从Linux(ARM32、Debian、RaspberryPi3B+)分析.NETCore控制台应用程序崩溃转储失败【英文标题】:Analysis.NETCoreconsoleappCrashdumpfromLinux(ARM32,Debian,RaspberryPi3B+)vialldbfailed【发布时间】:2019-01-1405:00:38【问题描述】:我在ARM32Linux物联网板(Raspb... 查看详情

为啥程序崩溃了,没有产生core文件

...通过系统服务启动的进程也可通过这一方法查看。二、若程序调用了seteuid()/setegid()改变了进程的有效用户或组,则在默认情况下系统不会为这些进程生成Coredump。很多服务程序都会调用seteuid(),如MySQL,不论你用什么用户运行mysq... 查看详情

minidump 文件对分析 .NET WinForms 应用程序崩溃有用吗?

】minidump文件对分析.NETWinForms应用程序崩溃有用吗?【英文标题】:Areminidumpfilesusefulforanalysing.NETWinFormsappcrashes?【发布时间】:2013-05-3109:56:20【问题描述】:小型转储文件对分析.NETWinForms应用程序崩溃有用吗?我注意到NBug可以选... 查看详情

coredump导出堆内存

参考技术A系统中,应用程序崩溃,一般会产生core文件,如何根据core文件查找问题的所在,并做相应的分析和调试,是非常重要的。什么是CoreDump?Core的意思是内存,Dump的意思是扔出来,堆出来.开发和使用Unix程序时,有时程序莫名... 查看详情

`generate-core-file` 是不是允许与检查“实时”崩溃一样多的自省和分析?

】`generate-core-file`是不是允许与检查“实时”崩溃一样多的自省和分析?【英文标题】:Will`generate-core-file`allowasmuchintrospectionandanalysisasinspectinga"live"crashdoes?`generate-core-file`是否允许与检查“实时”崩溃一样多的自省和分析... 查看详情

coredump(代码片段)

...mentationfault(coredumped)$./core.out段错误(核心已转储)运行一个程序,不小心发生了段错误(核心已转储),多悲催啊😆。幸好我们有coredump,能够帮助调试程序崩溃问题。今天我们就来聊一聊coredump。概述coredum... 查看详情

一个jvm解释器bug在aarch64平台导致应用崩溃的问题分析

...型的问题,应用在X86正常运行,在AArch64上JVM就会崩溃。这个典型的JVM内部问题。笔者通过分析最终定位到是由于JVM中模板解释器代码存在bug导致在弱内存模型的平台上Crash。在分析过程中,涉及到非常多的JVM内部知识... 查看详情

程序员听到bug后的n种反应,太形象了

程序员的世界里,不止有代码,还有bug,bug,bug当出现bug时,程序员们的反应是怎样的呢? 查看详情

oracle19c生成大量core文件

在RAC环境里,经常会有core文件产生,产生的原因:程序崩溃,内核有可能把该程序当前内存映射到core文件里,方便程序员找到程序出现问题的地方。那么如何定位及追踪core呢?以下操作即是:1.查找到系统程序崩溃时产生的core... 查看详情

混淆后的bugly报错分析

bugly日志信息解读示例:Attempttoinvokeinterfacemethod'java.util.ArrayListh.i.a.c.a.a(h.i.a.c.d.e)'onanullobjectreferenceAttempttoinvokevirtualmethod'android.view.ViewTreeObserverandroid.widget.FrameLayout.getViewTreeObserver()'onanullobjectreference总结规律:... 查看详情

core文件相关

1:当一个程序崩溃时,在进程当前工作目录的core文件中复制了该进程的存储图像。core文件仅仅是一个内存映象(同时加上调试信息),主要是用来调试的。 当程序接收到以下UNIX信号会产生core文件:SIGABRT、SIGBUS、SIGEMT、SIGFPE... 查看详情

coredump详解(代码片段)

..._15471709/4868198一,什么是coredump我们经常听到大家说到程序core掉了,需要定位解决,这里说的大部分是指对应程序由于各种异常或者bug导致在运行过程中异常退出或者中止,并且在满足一定条件下(这里为什么... 查看详情

coredump详解(代码片段)

..._15471709/4868198一,什么是coredump我们经常听到大家说到程序core掉了,需要定位解决,这里说的大部分是指对应程序由于各种异常或者bug导致在运行过程中异常退出或者中止,并且在满足一定条件下(这里为什么... 查看详情