进程crash和coredump文件解析

程序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的方法。