{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.xiaopingtou.cn//data/attach/topic/topicKPo7gB.jpg', '推荐 u010973249 的文章《内核调试工具 — kdump & crash》','https://www.xiaopingtou.net/article-70235.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
kdump简介
kdump是系统崩溃的时候，用来转储运行内存的一个工具。 系统一旦崩溃，内核就没法正常工作了，这个时候将由kdump提供一个用于捕获当前运行信息的内核， 该内核会将此时内存中的所有运行状态和数据信息收集到一个dump core文件中以便之后分析崩溃原因。 一旦内存信息收集完成，可以让系统将自动重启。 kdump是RHEL5之后才支持的，2006被主线接收为内核的一部分。它的原理简单来说是在内存中保留一块 区域，这块区域用来存放capture kernel，当production kernel发生crash的时候，通过kexec把保留区域的 capure kernel给运行起来，再由捕获内核负责把产品内核的完整信息 - 包括CPU寄存器、堆栈数据等转储 到指定位置的文件中。kdump原理
kexec是kdump机制的关键，包含两部分： 内核空间的系统调用kexec_load。负责在生产内核启动时将捕获内核加载到指定地址。 用户空间的工具kexec-tools。将捕获内核的地址传递给生产内核，从而在系统崩溃的时候找到捕获内核的地址并运行。 kdump是一种基于kexec的内核崩溃转储机制。当系统崩溃时，kdump使用kexec启动到第二个内核。第二个内核通常 叫做捕获内核，以很小内存启动以捕获转储镜像。第一个内核保留了内存的一部分给第二个内核启动使用。 由于kdump利用kexec启动捕获内核，绕过了BIOS，所以第一个内核的内存得以保留。这是内存崩溃转储的本质。
捕获内核启动后，会像一般内核一样，去运行为它创建的ramdisk上的init程序。而各种转储机制都可以事先在init中实现。
为了在生产内核崩溃时能顺利启动捕获内核，捕获内核以及它的ramdisk是事先放到生产内核的内存中的。
生产内核的内存是通过/proc/vmcore这个文件交给捕获内核的。为了生成它，用户工具在生产内核中分析出内存的使用和
分布等情况，然后把这些信息综合起来生成一个ELF头文件保存起来。捕获内核被引导时会被同时传递这个ELF文件头的
地址，通过分析它，捕获内核就可以生成出/proc/vmcore。有了/proc/vmcore这个文件，捕获内核的ramdisk中的脚本就
可以通过通常的文件读写和网络来实现各种策略了。
kdump配置
RHEL5开始，kexec-tools是默认安装的。 如果需要调试kdump生成的vmcore文件，需要手动安装kernel-debuginfo包。 (1) 预留内存 可以修改内核引导参数，为启动捕获内核预留指定内存。 在/etc/grub.conf (一般为/boot/grub/grub.conf的软链接)中： crashkernel=Y@X，Y是为kdump捕获内核保留的内存，X是保留部分内存的起始位置。 默认为crashkernel=auto，可自行设定如crashkernel=256M。 (2) 配置文件 配置文件为/etc/kdump.conf，以下是几个常用配置： # path /var/crash 默认的vmcore存放目录为/var/crash/%HOST-%DATE/，包括两个文件：vmcore和vmcore-dmesg.txt # sshcrash简介
当系统崩溃时，通过kdump可以获得当时的内存转储文件vmcore，但是该如何分析vmcore呢？ crash是一个用于分析内核转储文件的工具，一般和kdump搭配使用。 使用crash时，要求调试内核vmlinux在编译时带有-g选项，即带有调试信息。 如果没有指定vmcore，则默认使用实时系统的内存来分析。 值得一提的是，crash也可以用来分析实时的系统内存，是一个很强大的调试工具。 crash使用gdb作为内部引擎，语法类似于gdb，命令的使用说明可以用crash使用
Analyze Linux crash dump data or a live system. crash [OPTION] NAMELIST MEMORY-IMAGE (dumpfile form) crash [OPTION] [NAMELIST] (live system form) 使用crash来调试vmcore，至少需要两个参数： NAMELIST：未压缩的内核映像文件vmlinux，默认位于/usr/lib/debug/lib/modules/$(uname -r)/vmlinux，由 内核调试信息包提供。 MEMORY-IMAGE：内存转储文件vmcore，默认位于/var/crash/%HOST-%DATE/vmcore，由kdump生成。 例如：# crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/%HOST-%DATE/vmcore (1) 错误类型 首先可以在vmcore-dmesg.txt中先查看错误类型，如： 1. divide error: 0000 [#1] SMP，除数为0造成内核崩溃，由1号CPU触发。 2. BUG: unable to handle kernel NULL pointer dereference at 000000000000012c，引用空指针。 这样一来就能知道引发内核崩溃的错误类型。 (2) 错误地点 RIP为造成内核崩溃的指令，Call Trace为函数调用栈，通过RIP和Call Trace可以确定函数的调用路径，以及在 哪个函数中的哪条指令引发了错误。 例如RIP为：[ KERNEL: /usr/lib/debug/lib/modules/2.6.32-358.el6.x86_64/vmlinux
DUMPFILE: vmcore [PARTIAL DUMP]
CPUS: 12
DATE: Fri Sep 19 16:47:01 2014
UPTIME: 7 days, 06:37:46
LOAD AVERAGE: 0.19, 0.05, 0.01
TASKS: 282
NODENAME: localhost.localdomain
RELEASE: 2.6.32-358.el6.x86_64
VERSION: #1 SMP Tue Oct 29 10:18:21 CST 2013
MACHINE: x86_64 (1999 Mhz)
MEMORY: 48 GB
PANIC: "Oops: 0002 [#1] SMP " (check log for details)
PID: 0
COMMAND: "swapper"
TASK: ffffffff81a8d020 (1 of 12) [THREAD_INFO: ffffffff81a00000]
CPU: 0
STATE: TASK_RUNNING (PANIC)
这些基本输出信息简单明了，可由sys命令触发。
(4) crash常用命令
bt：打印函数调用栈，displays a task's kernel-stack backtrace，可以指定进程号bt > 0 0 0 ffffffff81a8d020 RU 0.0 0 0 [swapper]
# struct task_struct ffffffff81a8d020
struct task_struct {
state = 0,
stack = 0xffffffff81a00000,
usage = {
counter = 2
},
flags = 2097408,
显示整个结构体的定义：
# struct task_struct
struct task_struct {
volatile long int state;
void *stack;
atomic_t usage;
unsigned int flags;
显示整个结构体的定义，以及每个成员的偏移：
# struct -o task_struct
struct task_struct {
[0] volatile long int state;
[8] void *stack;
[16] atomic_t usage;
[20] unsigned int flags;
...
显示结构体中的成员定义，以及它的偏移：
# struct task_struct.pid
struct task_struct {
[1192] pid_t pid;
}
显示结构体中成员的值：
# struct task_struct.pid ffffffff81a8d020
pid = 0
查看全局变量的值：
# p sysctl_tcp_rmem
sysctl_tcp_rmem = $4 =
{40960, 873800, 41943040}
查看percpu全局变量(加前缀per_cpu_)：
# p per_cpu__irq_stat
PER-CPU DATA TYPE:
irq_cpustat_t per_cpu__irq_stat; // 变量类型的声明
PER-CPU ADDRESSES:
[0]: ffff880028216540 // 0号CPU对应变量的地址
[1]: ffff880645416540
...
查看0号CPU对应变量的值：
# struct irq_cpustat_t ffff880028216540
struct irq_cpustat_t {
__softirq_pending = 0,
__nmi_count = 4780195,
irq0_irqs = 148,
...
(6) 反汇编和源码行
反汇编：
# dis ffffffffa021ba91 // 反汇编一条指令
# dis -l probe_2093+497 10 // 反汇编从某个地址开始的10条指令对于内核中的符号： # sym tcp_v4_do_rcv // 通过symbol，显示虚拟地址和源码位置 # sym ffffffff8149f930 // 通过虚拟地址，显示symbol和源码位置 对于模块中的符号： 需要先加载相应的模块进来，才能显示符号对应的源码： # mod // 查看模块 # mod -s module /path/to/module.ko // 加载模块 # sym symbol // 显示符号对应的模块源码，也可以用virtual address (7) 修改内存 提供动态的修改运行中内核的功能，以供调试，但是RHEL和CentOS上不允许。 wr：modifies the contents of memory. wr [-u | -k | -p] [-8 | -16 | -32 | -64] [address | symbol] value 使用例子： # p sysctl_tcp_timestamps
sysctl_tcp_timestamps = $3 = 1
# wr sysctl_tcp_timestamps 0
wr: cannot write to /dev/crash!
我勒个擦，/dev/crash的文件属性是rw，但是crash_fops中并没有提供写函数，所以还是只读的。 这个功能很有用，但被RHEL和CentOS禁止了，所以如需动态修改运行内核还是用systemtap吧。