arm linux应用程序crash分析一般方法

前言

linux的应用程序app开发过程中，出现一些应用程序的崩溃是比较常见的事情，根据不同的场景，往往有可以分成两类:
1.开发环境下，解决应用程序的崩溃往往有很多的方法，常规的例如：上下文看代码逻辑，版本回退缩代码bug范围，不同版本横向对比，printf打印跟踪代码运行，debug工具上，配置内核show出来kallsyms,配置coredump抓应用崩溃日志等等，方式方法有很多种，分析问题手段也比较多一些，相对难度小一些。
2.在生产环境下，手段往往比较少一些，因为一般发布版本的应用程序，app的debug符号都被strip掉了，内核的kallsyms可能都看不到(cat /proc/kallsyms无输出)，内核日志种dump出来的backtrace没有任何的函数名称，甚至有时候coredump都是不打开不配置的（也就是没有coredump的日志），全程只有一个内核的kmsg出来的信息，用来分析app的崩溃。如果这时候不掌握一些分析问题的基本方法论，全靠运气解决问题，恐怕会比较低效率，今天在这里为大家介绍我在日常开发过程中，针对linux应用开发中出现的应用程序崩溃的一些分析方法

---

一、定位问题的基本方法论

提示：以下是本篇文章正文内容，下面案例可供参考

1.1 生产环境下系统崩溃的日志信息示例

先看一个生产环境下，没有coredump日志，没有内核kallsyms参考，不能用gdb调试的linux app奔溃日志

[  407.407974] [0][527: stream xfer] stream xfer: unhandled page fault (11) at 0x6f2c1000, code 0x817
[  407.407985] [0][527: stream xfer] pgd = 811c0000
[  407.407991] [0][527: stream xfer] [6f2c1000] *pgd=010c5831, *pte=00000000, *ppte=00000000
[  407.408164] [0][527: stream xfer] CPU: 0 PID: 527 Comm: stream xfer Tainted: P           O      4.19.91 #1
[  407.408168] [0][527: stream xfer] Hardware name: Novatek Video Platform
[  407.408174] [0][527: stream xfer] PC is at 0x76e83ff8
[  407.408177] [0][527: stream xfer] LR is at 0x00039e4c
[  407.408182] [0][527: stream xfer] pc : [<76e83ff8>]    lr : [<00039e4c>]    psr: 200f0010
[  407.408188] [0][527: stream xfer] sp : 6cc7ae04  ip : 6f2c0fe8  fp : 6cc7af8c
[  407.408192] [0][527: stream xfer] r10: 702c1d18  r9 : 00000000  r8 : 00000000
[  407.408198] [0][527: stream xfer] r7 : 6f205008  r6 : 6cc7ae2c  r5 : 000cf9c0  r4 : 746a5030
[  407.408203] [0][527: stream xfer] r3 : 00000000  r2 : 000d0792  r1 : 7476106e  r0 : 6f205008
[  407.408210] [0][527: stream xfer] Flags: nzCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
[  407.408216] [0][527: stream xfer] Control: 10c5387d  Table: 011c0059  DAC: 00000055
[  407.408222] [0][527: stream xfer] CPU: 0 PID: 527 Comm: stream xfer Tainted: P           O      4.19.91 #1
[  407.408226] [0][527: stream xfer] Hardware name: Novatek Video Platform
[  407.408230] [0][527: stream xfer] Backtrace:
[  407.408237] [0][527: stream xfer] Function entered at [<800139ec>] from [<80013b14>]
[  407.408246] [0][527: stream xfer]  r7:6f2c1000 r6:803d1048 r5:0000000b r4:80d79100
[  407.408251] [0][527: stream xfer] Function entered at [<80013afc>] from [<80302b80>]
[  407.408255] [0][527: stream xfer] Function entered at [<80302b60>] from [<800103d8>]
[  407.408260] [0][527: stream xfer] Function entered at [<800103c4>] from [<80014c84>]
[  407.408264] [0][527: stream xfer] Function entered at [<80014be8>] from [<80014fd0>]
[  407.408275] [0][527: stream xfer]  r9:00000817 r8:81bf5200 r7:80d79100 r6:6f2c1000 r5:00000055 r4:80ca5fb0
[  407.408279] [0][527: stream xfer] Function entered at [<80014d60>] from [<80015190>]
[  407.408289] [0][527: stream xfer]  r10:702c1d18 r9:00000000 r8:803d4224 r7:80ca5fb0 r6:6f2c1000 r5:803d1048
[  407.408293] [0][527: stream xfer]  r4:00000817
[  407.408298] [0][527: stream xfer] Function entered at [<80015144>] from [<80009da0>]
[  407.408303] [0][527: stream xfer] Exception stack(0x80ca5fb0 to 0x80ca5ff8)
[  407.408311] [0][527: stream xfer] 5fa0:                                     6f205008 7476106e 000d0792 00000000
[  407.408321] [0][527: stream xfer] 5fc0: 746a5030 000cf9c0 6cc7ae2c 6f205008 00000000 00000000 702c1d18 6cc7af8c
[  407.408330] [0][527: stream xfer] 5fe0: 6f2c0fe8 6cc7ae04 00039e4c 76e83ff8 200f0010 ffffffff
[  407.408339] [0][527: stream xfer]  r8:10c5387d r7:10c5387d r6:ffffffff r5:200f0010 r4:76e83ff8

二、 分析这类什么都没有的app crash的一般方法论：

• 1.2.1 分析问题前，需要先准备什么？

  准备App发行版时候，同一时刻编译的带有debug信息的发布版本应用程序，姑且称之为App.debug
  怎么看App是不是有debug符号（arm-xxx-xxx-xxx-readelf -S App.debug | grep -i debug）

• 1.2.2 先定位App崩溃发生在内核空间，还是用户空间？

  • 收集有用的基础信息，比如，App crash时候的PC寄存器内容，LR寄存器内容，Bactrace中的地址
  • 看linux内核的配置，先了解自己linux内核配置是2GB内核+2GB用户，还是1GB用户+3GB内核，还是3GB用户+1GB内核，即，了解一下自己是定义内核的起始地址的。一般是2+2或者3+1,即，内核的起始地址是从0x80000000开始或者0xc0000000。通过这个内核符号的起始地址，就可以大致知道内核函数或者变量（统一称为内核符号）放置的地址，也可以通过查看内核编译生成的System.map或者cat /proc/kallsyms查看崩溃时候PC寄存器访问的地址，是在内核中，还是用户空间中
  • 如果可以重新编译内核，打开CONFIG_KALLSYMS=y,这样就可以通过cat /proc/kallsyms查看内核所有符号
  • 如果可以重新编译内核，配置CONFIG_COREDUMP=y,并配置文件系统中，在初始化时候，配置一下coredump

    # coredump setting