进程crash和coredump文件解析

文章介绍了如何有效地分析程序崩溃问题,包括检查coredump文件限制,使用gdb解析coredump文件以获取堆栈信息,以及通过objdump反汇编库文件定位crash的具体位置,特别是针对__malloc_init函数的示例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

程序crash是很头疼的问题,如何有效的进行分析至关重要,下面记录了常用的分析方法。

coredump文件解析

1.首先通过ulimit -c命令确认系统对coredump文件的限制,如果返回为0,需要通过(ulimit -c unlimited)解除限制。

2.找到嵌入式系统环境下对应程序产生的coredump文件,拷贝到host机器上,使用host机器上的交叉编译工具链解析coredump文件。

例如: ntoaarch64-gdb test-arm test-arm.core

(gdb) bt 指令查看进程挂掉的堆栈信息

#0  0x0000002900050884 in __malloc_init () at /builds/workspace/sdp700/build_aarch64/lib/c/alloc/malloc.c:224
#1  0x000000290005062c in __pthread_once (once_control=0x290009a0f0 <__malloc_once>, init_routine=0x2900050870 <__malloc_init>)
    at /builds/workspace/sdp700/build_aarch64/lib/c/1c/pthread_once.c:62
#2  0x0000002900050d6c in __malloc (size=40) at /builds/workspace/sdp700/build_aarch64/lib/c/alloc/malloc.c:561
#3  0x00000029000514f8 in __cxa_atexit (func=0x2903dd74c0, arg=0x2903e25050, dso=0x2903e25000)
    at /builds/workspace/sdp700/build_aarch64/lib/c/ansi/__cxa_atexit.c:23
#4  0x0000002903dd4e58 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

objdump

进程运行crash的时候也会有相应的crash信息,例如:

Process 9560186 (example-no-torch) terminated SIGSEGV code=1 fltno=11 ip=00000016527818c4(/usr/nfs_share/common/lib/libtest.so@__malloc_init+0x0000000000000014)
mapaddr=00000000000138c4. ref=0000000000000006
Memory fault (core dumped)

从crash信息可以看出mapaddr=00000000000138c4,我们可以使用objdump反汇编对应的库查找对应crash的地方。

例如:aarch64-**-objdump -S -d -C libtest.so

00000000000138b0 <__malloc_init>:
 138b0: b0000240 adrp x0, 5c000 <_DYNAMIC+0x398>
 138b4: a9bf7bfd stp x29, x30, [sp,#-16]!
 138b8: 910003fd mov x29, sp
 138bc: f9462c00 ldr x0, [x0,#3160]
 138c0: f9400000 ldr x0, [x0]
 138c4: 79400c00 ldrh w0, [x0,#6]
 138c8: 7100041f cmp w0, #0x1
 138cc: 540000a9 b.ls 138e0 <__malloc_init+0x30>

从反汇编的地址可以很明显的看出挂在了__malloc_init函数的ldrh指令里。

以上就是几种常用的分析进程crash的方法。

### 如何进行 Crash 调试内核 Dump 文件 #### 打开 Core Dump 文件 Crash 工具用于分析 Linux 内核转储文件 (vmcore),该工具能够解析 vmlinux 文件并读取核心转储数据。为了启动 crash 实用程序,需指定两个参数:vmlinux 文件路径以及 core dump 文件位置。 ```bash crash /usr/lib/debug/lib/modules/4.18.0-193.19.1.el8_2.x86_64/vmlinux vmcore ``` 此命令加载了特定版本的 vmlinux 符号表,并连接至名为 `vmcore` 的内存映像文件[^1]。 #### 查看 Kernel Panic Dump 文件 当发生内核恐慌时,系统会创建一个位于 `/var/crash/<timestamp>/dump.<timestamp>` 目录下的 dump 文件。这些文件同样可以通过 crash 进行深入调查: ```bash crash /path/to/vmlinux /var/crash/202007092214/dump.202007092214 ``` 这允许访问与崩溃时刻有关的具体细节,包括但不限于寄存器状态、调用链路以及其他环境上下文信息[^2]。 #### 利用 GDB 类似功能探索更多信息 由于 crash 是基于 GDB 构建而成,在其交互界面下执行许多类似于 GDB 的指令来获取更详细的诊断资料成为可能。例如: - **bt**: 显示当前线程完整的回溯跟踪; - **ps**: 展示所有正在运行的任务列表及其基本信息; - **log**: 输出 dmesg 缓冲区的内容,通常包含了触发崩溃之前的日志记录; - **dis**: 反汇编给定地址范围内的机器码为人类可读形式; 此外,还可以利用 crash 提供的独特命令集进一步挖掘潜在问题所在之处,比如查询 slab 分配情况(`slab`) 或者遍历整个进程树结构 (`tree pid`)[^3].
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值