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

最新推荐文章于 2024-05-01 15:13:50 发布

HarveyRou

最新推荐文章于 2024-05-01 15:13:50 发布

阅读量818

点赞数 13

分类专栏： # crash分析技巧文章标签： arm开发 linux 嵌入式 c语言 c++

本文链接：https://blog.csdn.net/mingllu/article/details/136835227

版权

crash分析技巧专栏收录该内容

1 篇文章 0 订阅

订阅专栏

前言

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
vi /etc/profile
echo 1 > /proc/sys/kernel/core_uses_pid
ulimit -c unlimited
echo "/var/log/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
```

1.2.3 如果发生在用户空间，是发生在App自生code中，还是发生中调用的系统调用或者链接的库中？

如果崩溃发生在APP自己的code中，我怎么定位？

arm-xxx-xxx-xxx-addr2line -a PC寄存器中的地址 -e  App.debug

如果崩溃发生在APP链接的库中，我该怎么下一步分析？

如果崩溃是发生在库里，往往arm-xxx-xxx-xxx-addr2line 出来的是？？这样的符号，表示没有实际的函数符号
（因为库中的debug信息都被strip掉了）
这个时候arm-xxx-xxx-xxx-addr2line -a LR寄存器中的地址 -e  App.debug
根据LR寄存器定位看看是调用了什么库函数,然后在其周围对库函数形参进行参数检查，比如空指针，或者参数范围检测等

附录：

附录1 pmap -p 进程PID 查看进程的内存分配情况


root@sampleuser:~$ pmap -q 156
156: /usr/bin/cam_app
0000000000010000    8484K rwxp    [ anon ]
0000000001692000     132K rw-p  [heap]
000000006d064000       4K ---p    [ anon ]
000000006d065000    8192K rw-p    [ anon ]
000000006d865000       4K ---p    [ anon ]
000000006d866000    8192K rw-p    [ anon ]
000000006e066000       4K ---p    [ anon ]
000000006e067000    8192K rw-p    [ anon ]
000000006e867000       4K ---p    [ anon ]
000000006e868000   10596K rw-p    [ anon ]
000000006f2c1000       4K ---p    [ anon ]
000000006f2c2000    8192K rw-p    [ anon ]
000000006fac2000       4K ---p    [ anon ]
000000006fac3000    8192K rw-p    [ anon ]
00000000702c3000       4K ---p    [ anon ]
00000000702c4000    9736K rw-p    [ anon ]
0000000070c46000       4K ---p    [ anon ]
0000000070c47000    8192K rw-p    [ anon ]
0000000071447000       4K ---p    [ anon ]
0000000071448000    8192K rw-p    [ anon ]
0000000071c48000       4K ---p    [ anon ]
0000000071c49000    8192K rw-p    [ anon ]
0000000072449000       4K ---p    [ anon ]
000000007244a000    8192K rw-p    [ anon ]
0000000072c4a000       4K ---p    [ anon ]
0000000072c4b000    8192K rw-p    [ anon ]
000000007344b000       4K ---p    [ anon ]
000000007344c000    8192K rw-p    [ anon ]
0000000073c4c000       4K ---p    [ anon ]
0000000073c4d000   12996K rw-p    [ anon ]
00000000748fe000       4K ---p    [ anon ]
00000000748ff000    8192K rw-p    [ anon ]
00000000750ff000       4K ---p    [ anon ]
0000000075100000    8192K rw-p    [ anon ]
0000000075900000     132K rw-p    [ anon ]
0000000075921000     892K ---p    [ anon ]
0000000075a37000     136K rw-s  /dev/log_vg
0000000075b00000     132K rw-p    [ anon ]
0000000075b21000     892K ---p    [ anon ]
0000000075c45000       4K ---p    [ anon ]
0000000075c46000      16K rw-p    [ anon ]
0000000075c4a000       4K ---p    [ anon ]
0000000075c4b000      16K rw-p    [ anon ]
0000000075c4f000       4K ---p    [ anon ]
0000000075c50000      16K rw-p    [ anon ]
0000000075c54000       4K ---p    [ anon ]
0000000075c55000      16K rw-p    [ anon ]
0000000075c59000       4K ---p    [ anon ]
0000000075c5a000    8192K rw-p    [ anon ]
000000007645a000       4K ---p    [ anon ]
000000007645b000    8192K rw-p    [ anon ]
0000000076c5b000     120K r-xp  /lib/libgcc_s.so.1
0000000076c79000      60K ---p  /lib/libgcc_s.so.1
0000000076c88000       4K r--p  /lib/libgcc_s.so.1
0000000076c89000       4K rw-p  /lib/libgcc_s.so.1
0000000076c8a000     984K r-xp  /usr/lib/libstdc++.so.6.0.25
0000000076d80000      60K ---p  /usr/lib/libstdc++.so.6.0.25
0000000076d8f000      20K r--p  /usr/lib/libstdc++.so.6.0.25
0000000076d94000      12K rw-p  /usr/lib/libstdc++.so.6.0.25
0000000076d97000       4K rw-p    [ anon ]
0000000076d98000     368K r-xp  /lib/libm-2.30.so
0000000076df4000      60K ---p  /lib/libm-2.30.so
0000000076e03000       4K r--p  /lib/libm-2.30.so
0000000076e04000       4K rw-p  /lib/libm-2.30.so
0000000076e05000    1200K r-xp  /lib/libc-2.30.so
0000000076f31000      64K ---p  /lib/libc-2.30.so
0000000076f41000       8K r--p  /lib/libc-2.30.so
0000000076f43000       4K rw-p  /lib/libc-2.30.so
0000000076f44000      12K rw-p    [ anon ]
0000000076f47000       4K r--p  /usr/bin/cam_app
0000000076f48000     128K r-xp  /lib/ld-2.30.so
0000000076f68000      64K ---p    [ anon ]
0000000076f78000       4K r--p  /lib/ld-2.30.so
0000000076f79000       4K rw-p  /lib/ld-2.30.so
0000000076f7a000       8K rw-s  /dev/nvtmpp
0000000076f7c000       8K rw-s  /dev/nvtmpp
0000000076f7e000       4K rw-s  /SYSV474f4c48
0000000076f7f000       8K rw-p    [ anon ]
0000000076f81000      92K r-xp  /lib/libpthread-2.30.so
0000000076f98000      60K ---p  /lib/libpthread-2.30.so
0000000076fa7000       4K r--p  /lib/libpthread-2.30.so
0000000076fa8000       4K rw-p  /lib/libpthread-2.30.so
0000000076fa9000       8K rw-p    [ anon ]
0000000076fab000      24K r-xp  /lib/librt-2.30.so
0000000076fb1000      60K ---p  /lib/librt-2.30.so
0000000076fc0000       4K r--p  /lib/librt-2.30.so
0000000076fc1000       4K rw-p  /lib/librt-2.30.so
0000000076fc2000       8K rw-p    [ anon ]
000000007eaff000     132K rw-p  [stack]
000000007edf6000       4K r-xp  [sigpage]

附录2 cat /proc/pid/maps

root@HK100EB3104D1006:~$ cat /proc/156/maps
00010000-00859000 rwxp 00000000 00:00 0
01b36000-01b57000 rw-p 00000000 00:00 0          [heap]
6cf64000-6cf65000 ---p 00000000 00:00 0
6cf65000-6d765000 rw-p 00000000 00:00 0
6d765000-6d766000 ---p 00000000 00:00 0
6d766000-6df66000 rw-p 00000000 00:00 0
6df66000-6df67000 ---p 00000000 00:00 0
6df67000-6e767000 rw-p 00000000 00:00 0
6e767000-6e768000 ---p 00000000 00:00 0
6e768000-6f1c1000 rw-p 00000000 00:00 0
6f1c1000-6f1c2000 ---p 00000000 00:00 0
6f1c2000-6f9c2000 rw-p 00000000 00:00 0
6f9c2000-6f9c3000 ---p 00000000 00:00 0
6f9c3000-701c3000 rw-p 00000000 00:00 0
701c3000-701c4000 ---p 00000000 00:00 0
701c4000-70ff7000 rw-p 00000000 00:00 0
70ff7000-70ff8000 ---p 00000000 00:00 0
70ff8000-717f8000 rw-p 00000000 00:00 0
717f8000-717f9000 ---p 00000000 00:00 0
717f9000-71ff9000 rw-p 00000000 00:00 0
71ff9000-71ffa000 ---p 00000000 00:00 0
71ffa000-727fa000 rw-p 00000000 00:00 0
727fa000-727fb000 ---p 00000000 00:00 0
727fb000-72ffb000 rw-p 00000000 00:00 0
72ffb000-72ffc000 ---p 00000000 00:00 0
72ffc000-737fc000 rw-p 00000000 00:00 0
737fc000-737fd000 ---p 00000000 00:00 0
737fd000-73ffd000 rw-p 00000000 00:00 0
73ffd000-73ffe000 ---p 00000000 00:00 0
73ffe000-747fe000 rw-p 00000000 00:00 0
747fe000-747ff000 ---p 00000000 00:00 0
747ff000-74fff000 rw-p 00000000 00:00 0
74fff000-75000000 ---p 00000000 00:00 0
75000000-75800000 rw-p 00000000 00:00 0
75800000-75821000 rw-p 00000000 00:00 0
75821000-75900000 ---p 00000000 00:00 0
75976000-75998000 rw-s 00000000 00:06 2369       /dev/log_vg
75a00000-75a21000 rw-p 00000000 00:00 0
75a21000-75b00000 ---p 00000000 00:00 0
75b84000-75b85000 ---p 00000000 00:00 0
75b85000-75b89000 rw-p 00000000 00:00 0
75b89000-75b8a000 ---p 00000000 00:00 0
75b8a000-75b8e000 rw-p 00000000 00:00 0
75b8e000-75b8f000 ---p 00000000 00:00 0
75b8f000-75b93000 rw-p 00000000 00:00 0
75b93000-75b94000 ---p 00000000 00:00 0
75b94000-75b98000 rw-p 00000000 00:00 0
75b98000-75b99000 ---p 00000000 00:00 0
75b99000-76399000 rw-p 00000000 00:00 0
76399000-7639a000 ---p 00000000 00:00 0
7639a000-76b9a000 rw-p 00000000 00:00 0
76b9a000-76bb8000 r-xp 00000000 00:0c 621        /lib/libgcc_s.so.1
76bb8000-76bc7000 ---p 0001e000 00:0c 621        /lib/libgcc_s.so.1
76bc7000-76bc8000 r--p 0001d000 00:0c 621        /lib/libgcc_s.so.1
76bc8000-76bc9000 rw-p 0001e000 00:0c 621        /lib/libgcc_s.so.1
76bc9000-76cbf000 r-xp 00000000 00:0c 132        /usr/lib/libstdc++.so.6.0.25
76cbf000-76cce000 ---p 000f6000 00:0c 132        /usr/lib/libstdc++.so.6.0.25
76cce000-76cd3000 r--p 000f5000 00:0c 132        /usr/lib/libstdc++.so.6.0.25
76cd3000-76cd6000 rw-p 000fa000 00:0c 132        /usr/lib/libstdc++.so.6.0.25
76cd6000-76cd7000 rw-p 00000000 00:00 0
76cd7000-76d33000 r-xp 00000000 00:0c 624        /lib/libm-2.30.so
76d33000-76d42000 ---p 0005c000 00:0c 624        /lib/libm-2.30.so
76d42000-76d43000 r--p 0005b000 00:0c 624        /lib/libm-2.30.so
76d43000-76d44000 rw-p 0005c000 00:0c 624        /lib/libm-2.30.so
76d44000-76e70000 r-xp 00000000 00:0c 617        /lib/libc-2.30.so
76e70000-76e80000 ---p 0012c000 00:0c 617        /lib/libc-2.30.so
76e80000-76e82000 r--p 0012c000 00:0c 617        /lib/libc-2.30.so
76e82000-76e83000 rw-p 0012e000 00:0c 617        /lib/libc-2.30.so
76e83000-76e86000 rw-p 00000000 00:00 0
76e86000-76e87000 r--p 76eb9000 00:0c 217        /usr/bin/cam_app
76e87000-76ea7000 r-xp 00000000 00:0c 625        /lib/ld-2.30.so
76ea7000-76eb7000 ---p 00000000 00:00 0
76eb7000-76eb8000 r--p 00020000 00:0c 625        /lib/ld-2.30.so
76eb8000-76eb9000 rw-p 00021000 00:0c 625        /lib/ld-2.30.so
76eb9000-76ebb000 rw-s 03b7f000 00:06 2374       /dev/nvtmpp
76ebb000-76ebd000 rw-s 03b7f000 00:06 2374       /dev/nvtmpp
76ebd000-76ebe000 rw-s 00000000 00:05 0          /SYSV474f4c48 (deleted)
76ebe000-76ec0000 rw-p 00000000 00:00 0
76ec0000-76ed7000 r-xp 00000000 00:0c 626        /lib/libpthread-2.30.so
76ed7000-76ee6000 ---p 00017000 00:0c 626        /lib/libpthread-2.30.so
76ee6000-76ee7000 r--p 00016000 00:0c 626        /lib/libpthread-2.30.so
76ee7000-76ee8000 rw-p 00017000 00:0c 626        /lib/libpthread-2.30.so
76ee8000-76eea000 rw-p 00000000 00:00 0
76eea000-76ef0000 r-xp 00000000 00:0c 611        /lib/librt-2.30.so
76ef0000-76eff000 ---p 00006000 00:0c 611        /lib/librt-2.30.so
76eff000-76f00000 r--p 00005000 00:0c 611        /lib/librt-2.30.so
76f00000-76f01000 rw-p 00006000 00:0c 611        /lib/librt-2.30.so
76f01000-76f03000 rw-p 00000000 00:00 0
7eb52000-7eb73000 rw-p 00000000 00:00 0          [stack]
7ed8e000-7ed8f000 r-xp 00000000 00:00 0          [sigpage]

总结

其实，这种分析方法是最为简单的一种，有时候分析问题的时候，还需要依赖到具体代码文件，使用到objdump的工具，也是一种手段。
什么时候使用arm-xxx-xxx-xxx-objdump,通常是我们没有App.dbug文件的时候，这时候，我们根据PC寄存器地址，无法addr2line到具体的代码的时候，又没有其他的手段进行分析，可以根据PC或者LR的寄存器地址，找到App编译时候的对应的文件，反汇编该文件，然后利用函数的lr地址-函数基地址=偏移地址，计算具体的代码行，并根据对应的汇编代码，进行分析

HarveyRou

关注

13
点赞
踩
10

收藏

觉得还不错? 一键收藏
0
评论
arm linux应用程序crash分析一般方法

linux的应用程序app开发过程中，出现一些应用程序的崩溃是比较常见的事情，根据不同的场景，往往有可以分成两类:1.开发环境下，解决应用程序的崩溃往往有很多的方法，常规的例如：上下文看代码逻辑，版本回退缩代码bug范围，不同版本横向对比，printf打印跟踪代码运行，debug工具上，配置内核show出来kallsyms,配置coredump抓应用崩溃日志等等，方式方法有很多种，分析问题手段也比较多一些，相对难度小一些。
复制链接

扫一扫