前言

linux 程序崩溃，如果能根据已有的插桩日志能排查出来自然好，但是往往日志未全覆盖，这时候大海捞针排查起来还是比较麻烦的。
一般来说有以下这几种方法获取崩溃现场数据。

core dump

core dump是linux原生自带的一个异常分析工具，当程序运行的过程中异常终止或崩溃，操作系统会将程序当时的内存状态记录下来，保存在一个文件中。注意程序编译需要带 -g。

开启core dump

linux 默认是关闭的。

开启

ulimit -c unlimited

此时，运行程序发生sigsegv之类的异常时，自动生成core文件在执行文件目录下。

随便写一个简单错误代码，做测试

957: int *a = NULL;
958:    *a = 6; //非法，段错误

生成core文件后，执行

gdb <可执行程序> core

随后你就可以看到,如下提示，指名在那个文件那个函数的那一行触发异常，如上为958行

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/a7_softfp_neon-vfpv4/libthread_db.so.1".
Core was generated by `./JanusFace'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xacdd0d0c in test::testFunc (this=0x877f8550, stInfo=...) at testServer.cpp:958
958 testServer.cpp: No such file or directory.

这里的测试代码比较简单，如果是具体业务中的可能就要利用上gdb的那些功能，bt full 、查看栈帧，查看局部变量值之类的，方便具体问题具体分析。

(gdb) bt full
#0  0xacdd0d0c in test::testFunc (this=0x877f8550, stVideoViewReqInfo=...) at testServer.cpp:958iRet = -1a = 0x0__PRETTY_FUNCTION__ = "void test::testFunc(VIDEO_VIEW_REQ_INFO&)"

如上所示，局部变量a = 0 为空指针。

backtrace

有时候不方便gdb的时候，那就只能用backtrace之类的函数来辅助分析排查了
注册如sigsegv之类异常信号的异常处理函数，在处理函数中用backtrace查看调用堆栈。

      void SigSegv_handler(int signo){int j, nptrs;void *buffer[BT_BUF_SIZE];char **strings;nptrs = backtrace(buffer, BT_BUF_SIZE);printf("backtrace() returned %d addresses\n", nptrs);/* The call backtrace_symbols_fd(buffer, nptrs, STDOUT_FILENO)would produce similar output to the following: */strings = backtrace_symbols(buffer, nptrs);if (strings == NULL) {perror("backtrace_symbols");exit(EXIT_FAILURE);}for (j = 0; j < nptrs; j++)printf("%s\n", strings[j]);free(strings);exit(-1);}

如上即可获取调用堆栈

静态库

静态库打印的信息大致如下

Dump stack start...
backtrace() returned 8 addresses[00] ./backtrace(dump+0x1f) [0x400a9b][01] ./backtrace(signal_handler+0x31) [0x400b63][02] /lib/x86_64-linux-gnu/libc.so.6(+0x36150) [0x7f86afc7e150][03] ./backtrace(testFunc+0x1a) [0x400a3e]
Dump stack end...

比较简单，根据addr2line命令

addr2line -e backtrace 0x400a3e
testServer.cpp:958

动态库

动态库则略微麻烦，动态库每次加载的内存地址都不一样，所以不能跟静态库一样，不过可以根据根据map文件找到对应实际地址，编译的时候加上-Wl,-Map,entry.map。即可生成map文件。需要带 -g

动态库backtrace 打印如下。

Dump stack start...
backtrace() returned 8 addresses[00] ./backtrace(dump+0x1f) [0x400a53][01] ./backtrace(signal_handler+0x31) [0x400b1b][02] /lib/x86_64-linux-gnu/libc.so.6(+0x36150) [0x7f8583672150][03]./libTest.so(_ZN13Testt11testFuncER20_VIDEO_VIEW_REQ_INFO+**0x44**) [0xace45d0c]
Dump stack end...
段错误 (核心已转储)

在map文件中搜索testFunc

  0x0007fcc8                test::testFunc(_VIDEO_VIEW_REQ_INFO&)

可知在代码 0x0x0007fcc8 + 0x44处发生异常。

addr2line -e libTest.so 0x7FD0C
testServer.cpp:958

最后补充几句

mcu和linux这些处理crash基本思路都是一样的，linux里面的sigsegv这些诸如此类的异常，基本等同于mcu里面的那些hardfault，只不过handler在linux里面需要程序取做注册挂载，mcu里面只需要按照启动文件提供函数实现即可。处理逻辑也大同小异，mcu里面根据发生hardfault时的寄存器获取当时fault的现场环境数据，然后再根据ide生成的map获取现场环境做分析，linux只不过工具上更多样复杂了，gdb 、core dump 、addr2line 和backtrace这些，提供了比mcu更高级的crash现场分析。

linux 程序crash 调试、原因分析及问题定位相关推荐

RV1108 EMMC 程序下载失败原因分析
RV1108 EMMC 程序下载失败原因分析目录 RV1108 EMMC 程序下载失败原因分析 1. 出现的现象硬件环境表现出的问题 2. 原因查找检查硬件 3. rv1108 bootloa ...
高并发编程-线程通信_使用wait和notify进行线程间的通信2_多生产者多消费者导致程序假死原因分析
文章目录概述 jstack或者可视化工具检测是否死锁(没有) 原因分析概述高并发编程-线程通信_使用wait和notify进行线程间的通信 - 遗留问题我们看到了应用卡住了 .... 怀疑是 ...
Windows程序crash该怎么分析？
一.crash率 1.计算公式日crash率 = 每日上报crash设备数 / 每日联网设备数 crash率 = 统计周期内每日crash率的平均值统计周期:默认BSC统计周期默认是按月统计 2. ...
linux 程序退出调试,Linux程序调试 - nbspnbspnbspC++nbsp技术中心 - C++博客
Linux下的段错误产生的原因及调试方法简而言之,产生段错误就是访问了错误的内存段,一般是你没有权限,或者根本就不存在对应的物理内存,尤其常见的是访问0地址. 一般来说,段错误就是指访问的内存超出了 ...
linux 程序退出调试,linux驱动程序调试常用方法(printk,OOP,strace,hacking,ioctl,/proc,kgdb)...
驱动程序开发的一个重大难点就是不易调试.本文目的就是介绍驱动开发中常用的几种直接和间接的调试手段,它们是: 利用printk 查看OOP消息利用strace 利用内核内置的hacking选项利用i ...
android app程序闪退原因分析
1.xml布局不合理,导致程序难以绘制界面,从而闪退,例如:<fragment>中放入<constraint>导致布局不合理 2.activity没有在manifest中申明 ...
linux进程退出没有log,Linux下应用进程消失原因分析-Go语言中文社区
应用部署在Linux环境下,如果出现未知原因导致应用进程被杀(应用日志中没有任何异常现象,日志出现中断现象),如果对于进程消失原因没有特别明确的方向,可以考虑从系统日志(/var/log/messag ...
Linux下应用进程消失原因分析
应用部署在Linux环境下,如果出现未知原因导致应用进程被杀(应用日志中没有任何异常现象,日志出现中断现象),如果对于进程消失原因没有特别明确的方向,可以考虑从系统日志方面查找原因. 命令参考 dme ...
iOS平台的应用程序调试与分析
本文阐述如何在iOS平台上对应用程序进行调试与分析,旨在指导新手分析iOS程序,高手请无视.内容包括软件硬件的准备.代码的解密.符号信息的获取.用gdb调试等,最后以京东LeBook为例子进行演示. ...

linux 程序crash 调试、原因分析及问题定位

目录标题

前言

core dump

开启core dump

backtrace

静态库

动态库

最后补充几句

linux 程序crash 调试、原因分析及问题定位相关推荐

最新文章

热门文章