android 电视core dump分析

当在测试Android TV时遇到系统因操作DTMB频道重启并生成core dump文件,本文档详细介绍了如何分析和调试core dump。首先,通过设置ulimit -c unlimited和修改core_pattern来开启core dump生成。接着,利用file命令和gdb确定崩溃程序,并找到带有调试信息的二进制文件。最后,使用gdb进行core dump调试,通过bt命令查看堆栈信息,定位到问题可能出现在middleware/src/MW_DTV_Program_DVB.cpp的600行,怀疑是由于最近的代码改动导致的问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

测试测了个bug, 操作dtmb 频道的时候系统重启, 由于生成了core dump文件,所以先看下core dump。

一 . 要想调试core dump,首先要生成core dump, 一般只有c/c++编译生成的二进制程序崩溃了才会生成core dump, 一般需要以下设置。

1)

运行ulimit -c  unlimited

 ----> 要置成unlimited, 这个代表core dump文件大小,默认是0, 即不生成core dump

2)设置core dump文件路径以及文件名格式,

运行

echo '%e.core.%p' > /proc/sys/kernel/core_pattern

其中%e代表程序名, %p代表进程号

3) 有人说要关闭android系统的watch dog(这个我不太确定是否影响),我们是在工厂模式里关闭,其他android电视或者手机不知道在哪关了。

命令1) 是每次开机都要运行的,如果嫌麻烦,可以把命令写到initrc文件里。因为是在boot.img里,需要重烧版本了。



二. 准备工作

要调试core dump首先需要满足两点

第一点)需要知道是哪个程序崩溃生成的core dump

方法一, 运行 file Coredump.gz

结果

Coredump.gz: ELF 32-bit LSB  core file ARM, version 1 (SYSV), SVR4-style, from '/applications/bin/tvos'

看到了吗, 是tvos程序, 路径在电视falsh 中的/applications/bin/下

方法二

运行 

arm-none-linux-gnueabi-gdb /bin/ls ~/Coredump.gz

结果如下

.............

[New LWP 3129]
[New LWP 3956]
[New LWP 1724]
[New LWP 1746]
Core was generated by `/applications/bin/tvos'.
Program terminated with signal 6, Aborted.
#0  0x4120d976 in ?? ()
(gdb)

同样显示的是tvos程序

i)这里我们用了一个小技巧,先随便写了一个程序的路径,例如我们上面写的是/bin/ls,  那么gdb打开后,就会告诉我们,这个core dump文件是/applications/bin/tvos生成的。

ii)arm-none-linux-gnueabi-gdb 是调试core的程序,这个是厂商提供给我们的。从名字可以看出来,我们板子用的cpu是arm的。


第二点)

我们需要的二进制程序tvos是需要带调试信息的,发布给用的都是不带符号表的,因为符号表会增大程序体积大小。之前我调试的时候就是用了不带符号表的二进制程序,所以死活打不出堆栈来。

一般要找到二进制程序都在symbol目录下,

比如

pengpai@pub:~/A71S/E6700_A71S_Update_GridUI_svn2261_20150318/trunk/Supernova$ find -name tvos
./develop/include/tvos
./core/muf/tvos
./target/europ

### 如何在Android上使用GDB生成和分析coredump文件 #### 配置环境准备 为了能够在Android设备上利用GDB进行core dump的生成与分析,需先确保已安装适当版本的Android NDK以及设置好开发环境。对于C++开发的应用而言,这一步骤尤为关键[^2]。 #### 启用Core Dump功能 针对较新版本的Android系统(如P及以上),核心转储(coredump)支持已被集成到操作系统内部。要激活此特性并允许应用崩溃时创建core dump文件,可以通过修改`/proc/sys/kernel/core_pattern`来指定core文件存储路径及其命名模式[^3]。 例如,在具有root权限的情况下执行如下命令可将core dumps放置于特定目录: ```bash echo "/data/local/tmp/core-%e.%p" > /proc/sys/kernel/core_pattern ``` 此处`%e`代表执行文件名而`%p`表示进程ID。 #### 编译带有调试信息的应用程序 当通过NDK构建项目时,应启用编译选项以保留完整的调试符号表。这样做的目的是为了让后续借助gdb工具读取core dump变得更为容易。具体来说可以在`Application.mk`中加入以下配置项: ```makefile APP_CFLAGS += -g -O0 ``` 上述指令告知编译器尽可能多地嵌入源码级别的元数据,并关闭优化措施以便更精确地映射机器指令回原始代码片段。 #### 使用ADB启动目标app并与远程GDB连接 一旦应用程序部署完毕并且处于等待状态,就可以采用adb shell方式进入终端界面进而触发一次预期中的crash事件从而获取相应的core dump样本;之后再运用预先设定好的脚本来加载该二进制镜像连同其关联的核心转储一起送至本地计算机上的GNU Debugger实例里做进一步剖析工作[^1]。 下面给出一段Python脚本作为示范,用于自动化处理以上流程: ```python import os,subprocess,time,json,re def get_device_info(): result=subprocess.run(['adb','devices'],stdout=subprocess.PIPE).stdout.decode('utf-8') devices=[line.split('\t')[0]for line in result.strip().splitlines()[1:]if 'device' in line] return json.dumps({'devices':devices}) def setup_gdbserver(app_package_name,port=5039): subprocess.call(f'adb shell am force-stop {app_package_name}',shell=True) time.sleep(2)# wait for app to stop completely pid_output=subprocess.check_output( f'adb shell pgrep -f {re.escape(app_package_name)}',stderr=subprocess.STDOUT, universal_newlines=True) pids=re.findall(r'\d+',pid_output) if not pids: raise Exception("Failed to find PID of the application.") main_pid=pids[-1] gdb_server_command=f"gdbserver :{port} --attach {main_pid}" print(f'Setting up GDB server with command:{gdb_server_command}') adb_shell_process=subprocess.Popen( ['adb','-s',json.loads(get_device_info())['devices'][0],'shell'], stdin=subprocess.PIPE, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL ) adb_shell_process.stdin.write(gdb_server_command.encode()) adb_shell_process.stdin.close() adb_shell_process.wait() setup_gdbserver('com.example.yourapplication') ``` 这段代码实现了自动停止给定包名的目标App、查询其正在运行的服务进程号(PID),并通过ADB Shell向远端注入一条命令开启监听模式下的gdbserver服务,最后绑定选定端口等待来自PC侧发起的会话请求。 #### 加载core dump至本地GDB 完成前面几步操作后,现在可以回到电脑这边打开一个命令提示符窗口输入类似这样的语句把之前收集起来的数据导入进来查看问题所在了: ```bash $ arm-linux-androideabi-gdb ./obj/local/arm64-v8a/libyourlib.so ... (gdb) target remote tcp::5039 Remote debugging using tcp::5039 ... (gdb) core-file /path/to/the.core ... ``` 这里假设读者已经下载好了匹配架构类型的交叉编译版GDB客户端软件包,并且知道怎样定位到待检视库文件的确切地址。按照指示逐步建立起双向通信链路直至成功附加到远程进程中去,紧接着便是调用`core-file`命令传参指向先前所提到过的那部分内存快照资料来进行最终阶段的故障排查作业了。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值