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

最新推荐文章于 2024-08-07 14:55:49 发布
最新推荐文章于 2024-08-07 14:55:49 发布
阅读量1.1k 收藏 10
点赞数 13
分类专栏： # crash分析技巧 文章标签： arm开发 linux 嵌入式 c语言 c++
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/MingLLu/article/details/136835227
版权

目录：

前言

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
关注
专栏目录
树莓派 linux ARM 如何更新libc库
南七小僧的学海无涯
06-07 337
到 http://www.gnu.org/software/libc/libc.html 或 Index of /pub/gnu/libc下载你要的LIBC库。如果你的开发板用的是Ubunt的根文件系统，那么恭喜你，你要更新LIBC库就变得很简单。笔者采用的是nfs根文件系统更新ARM上的库。3. 拷贝PC使用的交叉编译工具的arm-linux-gnueabihf/libc/usr/lib 的所有。/arm/lib/arm-linux-gnueabi/ -d //-d 代表拷贝软连接。
ARM Linux崩溃分析（二）- 驱动程序导致系统崩溃的实例分析
重拾程序之路
04-18 3695
一、 测试用例 写了一个简单的测试程序进行测试： 代码如下： #include <linux/compat.h> #include <linux/kernel.h> #include <linux/module.h> #include <linux/device.h> #include <linux/pci.h> #include &lt...
Linux Kdump和Crash工具
chi's blog
01-04 1378
Kdump是一种基于kexec的Linux内核崩溃捕获机制，简单来说系统启动时会预留一块内存，当系统崩溃调用命令kexec(kdump kernel)在预留的内存中启动kdump内核，该内核会将此时内存中的所有运行状态和数据信息收集到一个coredump文件中以便后续分析调试。
linux主机利用crash分析-var-crash
04-12
linux主机利用crash分析-var-crash-下的vmcore-的dump分析.pdf
重新认识一下Crash
最新发布
2301_78976656的博客
08-07 552
经过上述的探究，那么可以得出一个结论，只要通过来设置默认的异常处理，就可以捕获到所有异常而减少Crash了。kotlin代码解读复制代码实现这段代码后，发现仅仅子线程的异常得到了处理，而主线程中的异常虽然也能被记录，但是应用还是会Crash。
Linux内核Crash分析
NFTercel的博客空间
07-30 1220
在工作中经常会遇到一些内核crash的情况，本文就是根据内核出现crash后的打印信息，对其进行了分析，使用的内核版本为：Linux2.6.32。        每一个进程的生命周期内，其生命周期的范围为几毫秒到几个月。一般都是和内核有交互，例如用户空间程序使用系统调用进入内核空间。这时使用的不再是用户空间的栈空间，使用对应的内核栈空间。对每一个进程来说，Linux内核都会把两个不同的数据结构紧
crash分析linux系统vmcore/kdump异常
weixin_41558221的博客
05-21 926
当Linux系统内核发生崩溃的时候，可以通过 KEXEC+KDUMP 等方式收集内核崩溃之前的内存，生成一个转储文件vmcore。内核开发者通过分析该vmcore文件就可以诊断出内核崩溃的原因，从而进行操作系统的代码改进。那么Crash就是一个被广泛使用的内核崩溃转储文件分析工具.对调试来讲，gdb是非常适合的，但gdb始终是调试native的工具，不支持kernel信息显示，比如task信息之类的。
crash分析linux内核崩溃转储文件vmcore
weixin_42915431的博客
04-21 1万+
文章目录一、调试环境准备二、使用crash分析vmcore1、bt命令2、log命令3、dis命令4、mod命令5、sym命令6、ps命令7、files命令8、vm命令9、task命令10、kmem命令11、其它命令三、写在最后 我们在Kdump-内核崩溃转储服务中，介绍了kdump服务可以在系统崩溃时，生成崩溃转储文件vmcore，便于我们分析内核崩溃原因，那么，下面我们就来看下如何使用cras...
嵌入式linux应用程序崩溃,嵌入式Linux gdb core dump快速定位程序crash问题
weixin_34669783的博客
05-07 1257
指定生成 core dump 文件：echo "/tmp/core-%e-%p-%t" > /proc/sys/kernel/core_patternulimit -c unlimited复现问题之后，取出 /tmp 目录下面的 core dump文件运行:/opt/rk3308/bin/arm-rockchip-linux-gnueabihf-gdb uni_demo core-uni_d...
Native Crash .so crash分析方法
zhongnanjun_3的专栏
05-06 1295
Native Crash是指，在用户空间的C/C++代码发生的abort、段错误、指令异常等crash问题。如果Native Crash发生在应用APK，则导致应用异常崩溃闪退，如果发生在系统关键进程则导致Android 系统重启。 Native crash问题相对比java crash问题更难分析和定位。Native Crash问题的分析主要依赖Android tombstone 和coref...
Crash分析
04-20
NULL 博文链接：https://buptrock.iteye.com/blog/1887305
嵌入式系统/ARM技术中的基于嵌入式Linux的内核错误跟踪技术
11-09
Linux内核错误跟踪技术在嵌入式系统/ARM技术中的应用 随着嵌入式Linux系统的广泛采用，特别是在关键领域的应用，比如涉及生命安全和财产保护的系统，对系统的可靠性和安全性要求日益提升。为了满足安全完整性等级3...
linux 程序crash 调试、原因分析及问题定位
无人等人的博客
05-26 8778
linux 程序崩溃，如果能根据已有的插桩日志能排查出来自然好，但是往往日志未全覆盖，这时候排查起来还是比较麻烦的。 一般来说有以下这几种方法获取崩溃现场数据。 core dump core dump是linux原生自带的一个异常分析工具，当程序运行的过程中异常终止或崩溃，操作系统会将程序当时的内存状态记录下来，保存在一个文件中。注意程序编译 需要带 -g。 开启core dump linux 默认是关闭的。 开启 ulimit -c unlimited 此时，运行程序发生sigsegv之类的异常时
linux kernel crash问题分析解决
热门推荐
小雨点的博客
11-08 2万+
一，问题场景和环境 系统环境： redhat6.4 kernel：2.6.32-358 问题： 使用iptables给mangle表添加了一条规则，使用nfqueue做为target。当一个http请求命中这个规则之后，机器直接重启了。偶发性的出了两次问题，但是却在重启的机器上重现不了这个问题。 二，排查 1，查看messages，kernel和dmesg相关日志，未发
Linux内核 Crash分析
StevenYang2008的博客
07-08 733
在工作中经常会遇到一些内核crash的情况，本文就是根据内核出现crash后的打印信息，对其进行了分析，使用的内核版本为：Linux2.6.32。 每一个进程的生命周期内，其生命周期的范围为几毫秒到几个月。一般都是和内核有交互，例如用户空间程序使用系统调用进入内核空间。这时使用的不再是用户空间的栈空间，使用对应的内核栈空间。对每一个进程来说，Linux内核都会把两个不同的数据结构紧凑的存放在一个单独为进程分配的存储空间中：一个是内核态的进程堆栈，另一个是紧挨进程描述符的数据结构thread_info,叫线程
crash linux主要命令,crash分析
weixin_33694136的博客
04-28 1770
Machine Check Exception (MCE) 是CPU发现硬件错误时触发的异常(exception)，中断号是18，异常的类型是abort：导致MCE的原因主要有：总线故障、内存ECC校验错、cache错误、TLB错误、内部时钟错误，等等。不仅硬件故障会引起MCE，不恰当的BIOS配置、firmware bug、软件bug也有可能引起MCE。在 Linux 系统上，如果发生的MCE错...
linux进程 crash 分析工具,crash工具分析大型Linux服务器死锁实战
weixin_30456235的博客
05-04 1214
Linux服务器背景：CPUS: 40MEMORY: 127.6 GBMACHINE: x86_64 (2199 Mhz)Linux Kernel: 4.4.121TASKS: 19411其实这不算大型服务器，我见过大型的一般内存4T起步，300多个cpu.故障背景：客户发现系统卡死，手动触发了kdump.使用下面命令发现有3092个D状态进程。crash> ps | grep UN | ...
linux操作系统crash日志分析1
06-29 4884
PID: 3311 TASK: ffff880137798000 CPU: 0 COMMAND: "yyyyyy" #0 [ffff88013a603d18] machine_kexec at ffffffff81047b02 #1 [ffff88013a603d68] crash_kexec at ffffffff810d0f33 #2 [ffff88013a603e30] pa...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值