Crash工具用于解析Vmcore文件,Vmcore文件为通过kdump等手段收集的操作系统core dump信息,在不采用压缩的情况下,其相当于整个物理内存的镜像,所以其中包括了最全面、最完整的信息,对于分析定位各种疑难问题有极大的帮助。配置kdump后,在内核panic后,会自动进入kump流程,搜集Vmcore。
Crash工具即为专门用于分析vmcore文件的工具,其中提供了大量的实用分析命令,极大的提高了vmcore的分析效率。
在分析vmcore的过程中,常常需要解析内核某个流程中的关键变量的值,以便确认故障当时系统的状态,本文主要介绍变量的解析方法,主要分全局变量和局部变量两种情况。
1、全局变量解析非常简单,可通过在crash中直接p 打印,如:
点击(此处)折叠或打开
crash>p jiffies
jiffies=$3=5540265294
2、局部变量的解析比较复杂。
Vmcore搜集的仅为故障当时内存使用情况的一个快照,是静态信息,无法进行动态调试(虽然听说可以,但没见过~~),对于某个进程而言,在Vmcore中能发掘的进程上下文信息,通常只有堆栈和寄存器的值。而我们了解,通常局部变量在栈中分配,但也可能直接使用寄存器保存,所以可以(也只能)通过“寻找局部变量跟堆栈或寄存器的关系”来解析局部变量的值。所以这里分两种情况:
1)位于栈中的局部变量
这种情况比较常见,此时,局部变量必然位于某一级函数的堆栈中,该局部变量可能通过指针一级级向底层函数传递,所以可能位于多个函数的堆栈中,可以从不同的函数堆栈中解析。但解析会比较困难,难点在于难以确认相关变量在堆栈中的具体位置,解析方法很灵活,需要结合相关源代码,仔细分析流程,找到关键的点,更多的取决于分析者的经验和代码理解能力。
如下以实例说明解析过程:
vmcore中某阻塞的进程有如下的堆栈:
点击(此处)折叠或打开
crash>bt 9242
PID:9242 TASK:ffff8805f3a21540 CPU:4 COMMAND: "xxx"
#0[ffff8805f3a23428]schedule at ffffffff814f8b42
#1[ffff8805f3a234f0]schedule_timeout at ffffffff814f9a6d
#2[ffff8805f3a235a0]__down at ffffffff814fa992
#3[ffff8805f3a235f0]down at ffffffff81097c11
#4[ffff8805f3a23620]xfs_buf_lock at ffffffffa0523433[xfs]
#5[ffff8805f3a23650]_xfs_buf_find at ffffffffa05235f2[xfs]
#6[ffff8805f3a236c0]xfs_buf_get at ffffffffa05237db[xfs]
#7[ffff8805f3a23700]xfs_buf_read at ffffffffa0523e4c[xfs]
#8[ffff8805f3a23730]xfs_trans_read_buf at ffffffffa0519a98[xfs]
#9[ffff8805f3a23780]xfs_read_agf at ffffffffa04cfd26[xfs]
#10[ffff8805f3a237c0]xfs_alloc_read_agf at ffffffffa04cfe99[xfs]
#11[ffff8805f3a237f0]xfs_alloc_fix_freelist at ffffffffa04d28a1[xfs]
#12[ffff8805f3a238d0]xfs_alloc_vextent at ffffffffa04d2e16[xfs]
可以看出,进程阻塞在信号量上,需要解析如下函数中xfs_buf_t *bp变量的值,以确认其中bp->b_sema信号量的状态。
点击(此处)折叠或打开
void
xfs_buf_lock(
xfs_buf_t*bp)
{
trace_xfs_buf_lock(bp,_RET_IP_);
if (atomic_read(&bp->b_io_remaining))
blk_run_address_space(bp->b_target->bt_mapping);
down(&bp->b_sema);
XB_SET_OWNER(bp);
trace_xfs_buf_lock_done(bp,_RET_IP_);
}
该变量是通过入参从上级函数传入的,而跟踪上级函数会发现其为在上级函数_xfs_buf_find中分配的局部变量,解析方法有两种: