crash files command

显示的内容是当前上下文打开文件的信息


如果研究文件系统,可以参考该命令
crash> help files
NAME
  files - open files

SYNOPSIS
  files [-d dentry] | [-R reference] [pid | taskp] ...

DESCRIPTION
/*显示的内容是当前上下文打开文件的信息
 *信息包括
 *1]root dirctory and current working directory;
 *2]pointer to file discriptor, dentry struct, inode, file type and the pathname
 **/

  This command displays information about open files of a context.
  It prints the context's current root directory and current working
  directory, and then for each open file descriptor it prints a pointer
  to its file struct, a pointer to its dentry struct, a pointer to the
  inode, the file type, and the pathname.  
/*files 后没有参数,使用的就是当前上下文,也就是所说的当前进程;
 *进程的pid and taskp 可以指定进程
 **/

  If no arguments are entered,the current context is used.  
  The -R option, typically invoked from
  "foreach files", searches for references to a supplied number, address,
  or filename argument, and prints only the essential information leading
  up to and including the reference.  
 
  The -d option is not context
  specific, and only shows the data requested.

     -d dentry  given a hexadecimal dentry address, display its inode,
                super block, file type, and full pathname.
  -R reference  search for references to this file descriptor number,
                filename, or dentry, inode, or file structure address.
           pid  a process PID.
         taskp  a hexadecimal task_struct pointer.

EXAMPLES
  Display the open files of the current context:

    crash> files
    PID: 1320   TASK: e6915be0  CPU: 0   COMMAND: "sh"
    ROOT: /    CWD: /
     FD    FILE     DENTRY    INODE    TYPE  PATH
      0  e61ab6e0  e64485d8  e61b37a8  CHR   /dev/console
      1  d8651180  e675bbd8  e6758068  REG   /proc/sysrq-trigger
      2  e61ab6e0  e64485d8  e61b37a8  CHR   /dev/console
      8  e6b101e0  e64094d8  e684a1c8  REG   /dev/__properties__
     24  e63dc700  e6445eb8  e61ae8e8  CHR   /dev/tty
     25  e61ab6e0  e64485d8  e61b37a8  CHR   /dev/console

    
      Display the files opened by the "crond" daemon, which is PID 462:

    crash> files 1320
    PID: 1320   TASK: e6915be0  CPU: 0   COMMAND: "sh"
    ROOT: /    CWD: /
     FD    FILE     DENTRY    INODE    TYPE  PATH
      0  e61ab6e0  e64485d8  e61b37a8  CHR   /dev/console
      1  d8651180  e675bbd8  e6758068  REG   /proc/sysrq-trigger
      2  e61ab6e0  e64485d8  e61b37a8  CHR   /dev/console
      8  e6b101e0  e64094d8  e684a1c8  REG   /dev/__properties__
     24  e63dc700  e6445eb8  e61ae8e8  CHR   /dev/tty
     25  e61ab6e0  e64485d8  e61b37a8  CHR   /dev/console
 
  The -R option is typically invoked from "foreach files".  This example
  shows all tasks that have "/dev/pts/4" open:

    crash> foreach files -R pts/4
    PID: 18633  TASK: c310a000  CPU: 0   COMMAND: "crash"
    ROOT: /    CWD: /home/CVS_pool/crash
     FD    FILE     DENTRY    INODE    TYPE  PATH
      0  c1412850  c2cb96d0  c2cad430  CHR   /dev/pts/4
      1  c1412850  c2cb96d0  c2cad430  CHR   /dev/pts/4
      2  c1412850  c2cb96d0  c2cad430  CHR   /dev/pts/4
    
    ----
    
    PID: 23159  TASK: c10fc000  CPU: 1   COMMAND: "xterm"
    ROOT: /    CWD: /homes/anderson/
     FD    FILE     DENTRY    INODE    TYPE  PATH
      5  c1560da0  c2cb96d0  c2cad430  CHR   /dev/pts/4
 
  Display information about the dentry at address e64485d8:

    crash> files -d e64485d8
     DENTRY    INODE    SUPERBLK  TYPE  PATH
    e64485d8  e61b37a8  e630cc00  CHR   /dev/console

使用实例:

ssize_t alb_read(struct file *filp, char __user *buf, size_t len, loff_t *ppos)
{
    struct alb_driver_context *albdev = filp->private_data;
    struct albimage_dev *albimage = albdev->albimage;

   -----

}

想知道struct alb_driver_context *albdev,需要首先知道 file,  怎样知道file?

从task_struct的成员变量:


crash> struct task_struct.files ed415400
  files = 0xee17c280
crash> struct files_struct.file 0xee17c280
struct: invalid data structure reference: files_struct.file
crash> struct files_struct.fd_array 0xee17c280
  fd_array = {0xee0f82a0, 0xee0f82a0, 0xee0f82a0, 0xed402940, 0xed4d7c80, 0xed4d7a00, 0xed4d7820, 0xee13d200, 0xee13d660, 0xed4060c0, 0xed407f40, 0xed4debc0, 0xee0e5460, 0xed402c60, 0xedb8bf20, 0xee0e55a0, 0xee0e51e0, 0xee0e53c0, 0xedb9e8e0, 0xedbffaa0, 0xe137d5a0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}


crash> struct file.f_path 0xe137d5a0
  f_path = {
    mnt = 0xee01def0,
    dentry = 0xedd8a448
  }
crash> struct dentry.d_iname 0xedd8a448
  d_iname = "albimg\000\377\377\377\377\377\377\373\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\357\377\377"
crash> struct file 0xe137d5a0
struct file {
  private_data = 0xee203cc0,
--

}


crash> struct alb_driver_context 0xee203cc0
struct alb_driver_context {
  albimage = 0xed9142e0,
  write_from = 0xf3000000 struct: seek error: kernel virtual address: f3000000  type: "gdb_readmem_callback"
struct: seek error: kernel virtual address: f3000000  type: "gdb_readmem_callback"
<Address 0xf3000000 out of bounds>,
  read_from = 0xf5000000 struct: seek error: physical address: 0  type: "page table"
}


crash> struct albimage_dev 0xed9142e0
struct albimage_dev {
  ap_reset_bp_base = 0xfc821004,
  bp_image_load_base = 0xf3000000,
  bp_image_load_base_phy = 0x80000000,
  bp_image_size = 0x0,
  dev = 0xc0728d00 <tl7689_alb_device+8>,
  alb_context = 0xee203cc0
}

使用files command

crash> files
PID: 1487   TASK: ed415400  CPU: 0   COMMAND: "rild-tl"
ROOT: /    CWD: /
 FD    FILE     DENTRY    INODE    TYPE  PATH
  0  ee0f82a0  edc1f888  edb31830  CHR   /dev/null
  1  ee0f82a0  edc1f888  edb31830  CHR   /dev/null
  2  ee0f82a0  edc1f888  edb31830  CHR   /dev/null
  3  ed402940  ede20b30  eddae980  SOCK  
  4  ed4d7c80  edd7a6f0  ed4ede10  CHR   /dev/log/main
  5  ed4d7a00  edd74c40  ed4e39f0  CHR   /dev/log/radio
  6  ed4d7820  edd741a0  ed4e3270  CHR   /dev/log/events
  7  ee13d200  edd7ad50  ed4e8370  CHR   /dev/log/system
  8  ee13d660  edd1cee8  ee0887f0  REG   /dev/__properties__
  9  ed4060c0  edda3aa8  edc186c0  SOCK  
 10  ed407f40  edda3910  edc18540  SOCK  
 11  ed4debc0  ede634d0  ede6fba8  REG   /sys/devices/platform/tl7689_smd/k2u/modem_state/BPState
 12  ee0e5460  eded5dd8  ede6fa50  FIFO  
 13  ed402c60  eded5dd8  ede6fa50  FIFO  
 14  edb8bf20  edd64c40  ed40eb10  CHR   /dev/ttyN0
 15  ee0e55a0  eddf2228  eddf7490  REG   /sys/power/wake_lock
 16  ee0e51e0  eddf21a0  eddf7338  REG   /sys/power/wake_unlock
 17  ee0e53c0  edd77cc8  ed4e8df0  CHR   /dev/binder
 18  edb9e8e0  edf62910  ede29520  SOCK  
 19  edbffaa0  ede634d0  ede6fba8  REG   /sys/devices/platform/tl7689_smd/k2u/modem_state/BPState
 20  e137d5a0  edd8a448  ed546e50  CHR   /dev/albimg

还是files命令比较直接

<think>首先,用户的问题是关于如何使用 crash 工具调试 Linux 内核崩溃。我需要根据系统级指令和用户可见层的要求来构建回答。 系统级指令: 1. 所有行内数学表达式使用 $...$ 格式。 2. 独立公式使用 $$...$$ 格式并单独成段。 3. LaTeX 语法正确。 4. 使用中文回答。 5. 生成相关问题。 6. 回答中引用的段落末尾自然地添加引用标识,例如:[^1] 用户可见层: 1. 回答结构清晰,帮助用户逐步解决问题。 2. 尽量保证回答真实可靠。 参考引用: - [^1]: crash 工具介绍,用于离线分析内核转存文件。 - [^2]: Crash-Utility 用于分析内核 coredump 文件。 - [^3]: crash 工具的基本知识。 - [^4]: 需要内存崩溃转储文件或实时系统内存。 - [^5]: Crash 的使用案例。 用户的问题:"我想了解如何使用 crash 工具进行系统调试或错误分析 请问如何使用 crash 工具调试 Linux 内核崩溃" 所以,我需要提供一个结构清晰的指南,解释如何使用 crash 工具调试 Linux 内核崩溃。回答应该包括步骤、命令和示例。 关键点来自引用: - crash 用于分析内核转储文件(如 vmcore)。 - 需要内核映像(vmlinux)和转储文件。 - 可以用于离线分析或实时调试。 - 基本命令如查看堆栈、dmesg、数据结构等。 结构回答: 1. **引言**:简要介绍 crash 工具。 2. **准备工作**:如何获取必要的文件(内核映像和转储文件)。 3. **基本使用**:启动 crash 工具,加载文件。 4. **常用命令**:列出和分析内核崩溃的常用命令。 5. **示例分析**:提供一个简单的示例。 6. **总结**:强调重要性。 7. **相关问题**:生成相关问题。 确保使用中文回答。 生成相关问题:在回答末尾添加相关问题部分,如示例中的 "§§相关问题§§"。 引用标识:在回答中引用参考内容时,添加 [^n],例如提到功能时引用 [^1]。 数学表达式:用户的问题是关于调试工具,可能不涉及数学,但如果有,比如计算偏移等,使用 $...$。但在这个上下文中,可能不需要。 现在,构建回答大纲: - **步骤1: 介绍 crash 工具** - 解释 crash 是什么,用途 [^1][^2]。 - **步骤2: 准备工作** - 需要内核映像(vmlinux)和崩溃转储文件(vmcore)[^4]。 - 如何生成这些文件(使用 kdump 等)。 - **步骤3: 启动 crash** - 命令格式:`crash /path/to/vmlinux /path/to/vmcore` 或实时调试 `crash` [^4]。 - **步骤4: 基本命令** - `bt`:查看堆栈回溯。 - `log`:查看 dmesg 日志。 - `struct`:查看内核数据结构。 - `dis`:反汇编。 - 其他命令如 `ps`, `files` 等 [^2][^3]。 - **步骤5: 调试示例** - 假设一个崩溃场景,展示如何分析。 - **步骤6: 总结** - 强调 crash 的强大功能 [^3]。 - **相关问题** - 生成 3-4 个相关问题。 确保语言专业、清晰。</think>### 如何使用 crash 工具调试 Linux 内核崩溃 Linux 内核崩溃(如 panic 或 oops)是严重的系统错误,可能导致系统宕机。为了快速定位问题,可以使用 crash 工具——一个强大的开源工具,专门用于分析内核崩溃生成的转储文件(如 vmcore)。它整合了 gdb 功能,支持离线分析转储文件或实时调试运行时系统 [^1][^2]。以下我将逐步解释如何使用 crash 工具进行调试,确保回答基于可靠参考和实际实践。整个过程包括准备工作、启动工具、使用命令和分析示例。 #### 1. **准备工作:获取必要文件** 在调试前,需要两个关键文件: - **内核映像文件 (vmlinux)**:这是未压缩的内核符号文件,包含调试信息。通常位于 `/usr/lib/debug/lib/modules/$(uname -r)/vmlinux` 或编译内核时生成的路径。 - **崩溃转储文件 (vmcore)**:当内核崩溃时,通过 kdump 机制自动生成。确保 kdump 已启用: - 安装 kdump-tools:`sudo apt-get install kdump-tools`(Ubuntu)或 `sudo yum install kexec-tools`(CentOS)。 - 配置 kdump:编辑 `/etc/default/kdump-tools`,设置转储路径,然后重启服务:`sudo systemctl restart kdump-tools`。 - 崩溃后,转储文件通常保存在 `/var/crash/` 或指定目录 [^4]。 如果系统未崩溃,但需调试实时内核,crash 可直接访问 `/dev/mem` 或 `/proc/kcore`(需 root 权限)[^4]。确保文件权限正确:使用 `sudo` 或 root 用户操作。 #### 2. **启动 crash 工具** 根据场景选择启动方式: - **离线分析转储文件**:使用 vmlinux 和 vmcore 文件启动。 ```bash crash /path/to/vmlinux /path/to/vmcore ``` 例如:`crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/vmcore`。 - **实时调试运行时系统**:直接运行 `crash`,它会自动加载 `/proc/kcore` 作为内存转储 [^4]。 ```bash sudo crash ``` 启动后,进入 crash 交互式命令行界面,提示符变为 `crash>`。系统会显示崩溃摘要,如 panic 原因和寄存器状态 [^2]。 #### 3. **常用命令分析内核崩溃** crash 提供多种命令来诊断问题。以下是调试崩溃的核心命令(完整列表可通过 `help` 查看): - **`bt`(backtrace)**:查看崩溃时的堆栈回溯。这是第一步,用于定位触发崩溃的函数调用链。 ``` crash> bt ``` 输出显示每个 CPU 的堆栈帧,帮助识别错误源头 [^2]。 - **`log` 或 `dmesg`**:查看内核日志(dmesg),包含崩溃前后的错误消息。 ``` crash> log ``` 例如,搜索 "panic" 或 "Oops" 关键字,确定崩溃原因 [^1]。 - **`struct`**:检查内核数据结构。例如,分析任务结构 `task_struct` 以查看进程状态。 ``` crash> struct task_struct comm ``` 参数可指定字段(如 `comm` 表示进程名),辅助诊断资源泄漏或竞争条件 [^3]。 - **`dis`(disassemble)**:反汇编代码,分析汇编指令错误。 ``` crash> dis <function_name> ``` 例如:`dis sys_write`,检查函数实现是否有问题 [^1]。 - **`ps`**:列出所有进程状态,识别崩溃时活跃的进程。 ``` crash> ps ``` - **`kmem`**:分析内存使用,检测内存损坏或泄漏。 ``` crash> kmem -i ``` 显示内存统计信息,如分配和释放情况 [^3]。 - **`search`**:搜索内存中的特定值或字符串。 ``` crash> search -u <address> ``` 例如,搜索崩溃地址以关联数据。 这些命令可组合使用。例如,先 `bt` 找到问题函数,再 `struct` 检查相关数据结构,最后 `dis` 反汇编代码 [^2][^3]。 #### 4. **调试示例:分析一个简单崩溃** 假设系统因 NULL 指针解引用崩溃,dmesg 显示 "Unable to handle kernel NULL pointer dereference"。以下是分析步骤: 1. 启动 crash:`crash /path/to/vmlinux /path/to/vmcore`。 2. 查看堆栈回溯: ``` crash> bt PID: 0 TASK: ffff888007c00000 CPU: 0 COMMAND: "swapper/0" #0 [ffff888007c03df0] panic at ffffffff810e2345 #1 [ffff888007c03e50] oops_end at ffffffff81f0d7d3 #2 [ffff888007c03e80] no_context at ffffffff81f0b4a2 #3 [ffff888007c03ed0] __bad_area_nosemaphore at ffffffff81f0b5c1 #4 [ffff888007c03f20] bad_area at ffffffff81f0b7d0 #5 [ffff888007c03f50] __do_page_fault at ffffffff8100a8b0 #6 [ffff888007c03fa0] do_page_fault at ffffffff81f0c3a5 #7 [ffff888007c03fd0] page_fault at ffffffff82000bf5 ``` 输出显示 `panic` 由 `do_page_fault` 触发,表明内存访问错误。 3. 检查日志确认: ``` crash> log | grep panic Kernel panic - not syncing: Fatal exception ``` 4. 分析问题函数:假设 `bt` 指向 `my_driver_write` 函数,使用 `dis` 反汇编: ``` crash> dis my_driver_write 0xffffffffa0000000 <my_driver_write>: push %rbp 0xffffffffa0000001 <my_driver_write+1>: mov %rsp,%rbp 0xffffffffa0000004 <my_driver_write+4>: mov 0x10(%rdi),%rax # 访问 NULL 指针 ``` 反汇编显示指令 `mov 0x10(%rdi),%rax` 尝试访问无效地址。 5. 检查数据结构:使用 `struct` 查看 `rdi` 寄存器对应的结构。 ``` crash> struct file f_path.dentry @rdi ``` 输出可能显示 `dentry` 为 NULL,证实 NULL 指针解引用。 通过此过程,可定位到驱动代码中的 bug,并修复访问检查逻辑 [^2][^3]。 #### 5. **总结** crash 工具是 Linux 内核调试的核心利器,能高效分析转储文件或实时系统,帮助开发者快速诊断崩溃原因(如内存错误、竞争条件或驱动问题)。它整合了堆栈、日志和数据结构检查,减少调试时间 [^1][^3]。实践中,建议结合内核文档和社区资源(如 kernel.org)深入学习。记住:调试需 root 权限,确保文件路径正确以避免错误。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值