Linux内核调试方法总结之coredump

什么是core dump?

分析core dump是Linux应用程序调试的一种有效方式,像内核调试抓取ram dump一样,core dump主要是获取应用程序崩溃时的现场信息,如程序运行时的内存、寄存器状态、堆栈指针、内存管理信息、函数调用堆栈信息等。

Core dump又称为“核心转储”,是Linux基于信号实现的。Linux中信号是一种异步事件处理机制,每种信号都对应有默认的异常处理操作,默认操作包括忽略该信号(Ignore)、暂停进程(Stop)、终止进程(Terminate)、终止并产生core dump(Core)等。通常以下信号会触发core dump:

什么情况下会产生core dump呢?

以下情况会出现应用程序崩溃导致产生core dump:

  1. 内存访问越界 (数组越界、字符串无\n结束符、字符串读写越界)
  2. 多线程程序中使用了线程不安全的函数,如不可重入函数
  3. 多线程读写的数据未加锁保护(临界区资源需要互斥访问)
  4. 非法指针(如空指针异常或者非法地址访问)
  5. 堆栈溢出

怎么获取core dump呢?

Linux提供了一组命令来配置core dump行为:

1. ulimit –c 查看core dump机制是否使能,若为0则默认不产生core dump,可以使用ulimit –c unlimited使能core dump

2. cat /proc/sys/kernel/core_pattern 查看core文件默认保存路径,默认情况下是保存在应用程序当前目录下,但是如果应用程序中调用chdir()函数切换了当前工作目录,则会保存在对应的工作目录

3. echo “/data/xxx/<core_file>” > /proc/sys/kernel/core_pattern 指定core文件保存路径和文件名,其中core_file可以使用以下通配符:

%% 单个%字符

%p 所dump进程的进程ID

%u 所dump进程的实际用户ID

%g 所dump进程的实际组ID

%s 导致本次core dump的信号

%t core dump的时间 (由1970年1月1日计起的秒数)

%h 主机名

%e 程序文件名

4. ulimit –c [size] 指定core文件大小,默认是不限制大小的,如果自定义的话,size值必须大于4,单位是block(1block = 512bytes)

怎么分析core dump?

我们首先编写一个程序,人为地产生core dump并获取core dump文件。

程序如上图,我们通过除零操作产生core dump

编译运行产生了浮点数异常,从而引发core dump

当前目录下产生了core文件,使用file命令查看core文件类型

发现core文件类型为ELF格式,即可执行文件,使用readelf查看ELF文件头部信息如下

通过Type字段可以看到,该文件为core文件

前面我们讲到core dump可以查看应用程序崩溃时的现场信息,这里,我们需要gdb命令辅助实现,使用gdb test core(即test可执行文件和core文件)

其中打印出导致core dump产生的原因,即Arithmetic exception,同时打印出了出问题的代码行result = a/b; 这里可以注意到当前还处在gdb调试环境中。可以通过bt –n (backtrace)显示函数调用栈信息,n表示显示的调用栈层数。因为test.c调试程序不涉及函数调用,所以我们只能看到main函数的栈信息,如果程序是在main函数的子函数中出错,则可以打印更多的调用栈信息。

通过disassemble命令可以打印出错时的汇编代码片段,其中箭头指向的是错误行。

可以看到调用了div指令做除法操作,被除数是-0x8(%ebp),指当前栈基址向下偏移8个字节所在内存单元的数值,EBP是栈基址寄存器。同时我们可以看到前面通过movl $0x0, -0x8(%ebp)将0保存到该内存单元,证明被除数为0。

时间: 2024-10-07 14:15:01

Linux内核调试方法总结之coredump的相关文章

Linux内核调试方法总结之反汇编

Linux反汇编调试方法 Linux内核模块或者应用程序经常因为各种各样的原因而崩溃,一般情况下都会打印函数调用栈信息,那么,这种情况下,我们怎么去定位问题呢?本文档介绍了一种反汇编的方法辅助定位此类问题. 代码示例如下: #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <execinfo.h> #include <fcntl.h> #include <

Linux内核调试方法总结

一  调试前的准备 二  内核中的bug 三  内核调试配置选项 1  内核配置 2  调试原子操作 四  引发bug并打印信息 1  BUG()和BUG_ON() 2  dump_stack() 五  printk() 1  printk函数的健壮性 2  printk函数脆弱之处 3  LOG等级 4  记录缓冲区 5  syslogd/klogd 6  dmesg 7 注意 8 内核printk和日志系统的总体结构 9  动态调试 六  内存调试工具 1  MEMWATCH 2  YAMD

Linux内核调试方法总结之序言

本系列主要介绍Linux内核死机.异常重启类稳定性问题的调试方法. 在Linux系统中,一切皆为文件,而系统运行的载体,是一类特殊的文件,即进程.因此,我尝试从进程的角度分析Linux内核的死机.异常重启等问题.在内核空间,内核本身是一个特权级的进程,它包含一系列系统级线程,维护整个系统内核的运转.在用户空间,有很多用户进程实现不同的功能,它们有的是独立运行,有些相互之间有依赖(同步或者互斥).在32位系统中,内核进程独享3GB~4GB的高1GB内存空间,而每个用户进程则分别占据0GB~3GB的

Linux内核调试方法总结之ddebug

[用途] Linux内核动态调试特性,适用于驱动和内核各子系统调试.动态调试的主要功能就是允许你动态的打开或者关闭内核代码中的各种提示信息.适用于驱动和内核线程功能调试. [使用方法] 依赖于CONFIG_DYNAMIC_DEBUG内核配置选项,一旦设置好,那么所有pr_debug()/dev_debug()之类的内核调试函数就可以动态地打印日志到终端.通过读写<debugfs>/dynamic_debug/control文件在系统启动之后打开或者关闭调试日志. [参考] http://www

Linux内核调试方法总结之调试宏

本文介绍的内核调试宏属于静态调试方法,通过调试宏主动触发oops从而打印出函数调用栈信息. 1) BUG_ON 查看bug处堆栈内容,主动制造oops Linux中BUG_ON,WARN_ON用于调试,比如 #define BUG_ON(condition) do { / if (unlikely((condition)!=0)) / BUG(); / } while(0) 如果觉得该condition下是一个BUG,可以添加此调试信息,查看对应堆栈内容 具体的BUG_ON最终调用__bug _

Linux内核调试方法总结之sysrq

sysrq [用途] Sysrq被称为”魔术组合键”, 是内建于Linux内核的调试工具.只要内核没有完全锁住,不管内核在做什么事情,使用这些组合键都可以搜集包括系统内存使用.CPU任务处理.进程运行状态等系统运行信息. [原理][内核帮助文档kernel/Documentation/sysrq.txt] 首先,内核配置选项中要使能CONFIG_MAGIC_SYSRQ选项,这样系统启动之后,会生成/proc/sysrq-trigger节点用于调试. 其次,可以在/etc/sysctl.conf中

Linux内核调试方法总结之ptrace

ptrace [用途] 进程跟踪器,类似于gdb watch的调试方法 [原理][详细说明参考man ptrace帮助文档] ptrace系统调用主要是父进程用来观察和控制子进程的执行过程.检查并替换子进程执行序列或者寄存器值的一种手段.主要用于实现断点调试和跟踪系统调用. [接口说明] #include <sys/ptrace.h> long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data); 序

Linux内核调试方法总结之死锁问题分析

死锁问题分析 死锁就是多个进程(线程)因为等待别的进程已占有的自己所需要的资源而陷入阻塞的一种状态,死锁状态一旦形成,进程本身是解决不了的,需要外在的推动,才能解决,最重要的是死锁不仅仅影响进程业务,而且还会占用系统资源,影响其他进程.所以内核中设计了内核死锁检测机制,一旦发现死锁进程,就重启OS,快刀斩乱麻解决问题.之所以使用重启招数,还是在于分布式系统中可以容忍单点崩溃,不能容忍单点进程计算异常,否则进行死锁检测重启OS就得不偿失了. 内核提供自旋锁.信号量等锁形式的工具,具体不再赘述. L

Linux内核调试方法总结之ltrace

ltrace [用途] 库文件调用跟踪器,Linux内核内建命令,用法类似strace [命令格式] [参数说明][详细说明参考man ltrace帮助文档] -D 打印调试信息 01-DEBUG_GENERAL 010-DEBUG_EVENT 020-DEBUG_PROCESS 040-DEBUG_FUNCTION -f 同时跟踪当前进程创建的子进程(fork或者clone) -l 指定特定的库文件名 -o 指定输出文件名 -p 指定进程PID -r 打印相对时间 -S 打印系统调用 -T 打