Android crash 日志 分析

最新推荐文章于 2024-07-03 16:40:03 发布
最新推荐文章于 2024-07-03 16:40:03 发布
阅读量2.7w 收藏 22
点赞数 4
分类专栏： Linux 文章标签： android linux crash
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/jack_chen_00/article/details/36190485
版权

      在Android开发的过程中，有时候需要创建一个纯linux的应用程序，当这些程序crash时，如果找不到导致crash的直接原因，问题将很难被修复。本文将介绍一种分析crash问题的方法。

    1）以下是crash时串口的打印信息：

pid: 96, tid: 798, name: Playback  >>> /system/bin/dvb <<<
I/DEBUG   (   80): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr 00000000
I/DEBUG   (   80): Abort message: 'heap corruption detected by dlfree'
W/NativeCrashListener(  428): Couldn't find ProcessRecord for pid 96
I/DEBUG   (   80):     r0 00000000  r1 0000031e  r2 00000006  r3 00000000
I/DEBUG   (   80): AM write failure (32 / Broken pipe)
I/DEBUG   (   80):     r4 00000006  r5 00000016  r6 0000031e  r7 0000010c
I/DEBUG   (   80):     r8 000001b8  r9 00000000  sl 000001b8  fp 427dfcc8
I/DEBUG   (   80):     ip 000000bd  sp 4ad52c30  lr 41135075  pc 41144020  cpsr 080f0010
I/DEBUG   (   80):     d0  6465746372666c64  d1  206e6f6974707572
I/DEBUG   (   80):     d2  0000000000000000  d3  0000000000000000
I/DEBUG   (   80):     d4  3fe0000000000000  d5  3fd19b5cefffd79a
I/DEBUG   (   80):     d6  0000bb8031000000  d7  000000003f800000
I/DEBUG   (   80):     d8  0000000000000000  d9  0000000000000000
I/DEBUG   (   80):     d10 0000000000000000  d11 0000000000000000
I/DEBUG   (   80):     d12 0000000000000000  d13 0000000000000000
I/DEBUG   (   80):     d14 0000000000000000  d15 0000000000000000
I/DEBUG   (   80):     d16 8000000000000000  d17 0000000000000000
I/DEBUG   (   80):     d18 ffffffffffffffff  d19 0000000000000000
I/DEBUG   (   80):     d20 be926aa2f81b5123  d21 bf56882f94edacc2
I/DEBUG   (   80):     d22 3e21e0e0299e8cc5  d23 3ff0000000000000
I/DEBUG   (   80):     d24 3fe7325188001433  d25 3fd19b5cefffd79a
I/DEBUG   (   80):     d26 0000000000000000  d27 3f895d470d6e9486
I/DEBUG   (   80):     d28 3fe797c6a435ce85  d29 3e8f20d95f29baf8
I/DEBUG   (   80):     d30 bef375cbdb605373  d31 3fe7bc89cf9e1300
I/DEBUG   (   80):     scr 60000010
I/DEBUG   (   80): 
I/DEBUG   (   80): backtrace:
I/DEBUG   (   80):     #00  pc 00022020  /system/lib/libc.so (tgkill+12)
I/DEBUG   (   80):     #01  pc 00013071  /system/lib/libc.so (pthread_kill+48)
I/DEBUG   (   80):     #02  pc 00013285  /system/lib/libc.so (raise+10)
I/DEBUG   (   80):     #03  pc 00011fbb  /system/lib/libc.so
I/DEBUG   (   80):     #04  pc 000218d4  /system/lib/libc.so (abort+4)
I/DEBUG   (   80):     #05  pc 00012aa1  /system/lib/libc.so
I/DEBUG   (   80):     #06  pc 0000f1ad  /system/lib/libc.so
I/DEBUG   (   80):     #07  pc 0001177b  /system/lib/libc.so (dlfree+1222)
I/DEBUG   (   80):     #08  pc 0000dcc3  /system/lib/libc.so (free+10)
I/DEBUG   (   80):     #09  pc 0004a0e7  /system/lib/libmcp.so (mespSkip+172)
I/DEBUG   (   80):     #10  pc 00026987  /system/lib/libmcp.so
I/DEBUG   (   80):     #11  pc 000a58bd  /system/lib/libmcp.so
I/DEBUG   (   80):     #12  pc 0000d228  /system/lib/libc.so (__thread_entry+72)
I/DEBUG   (   80):     #13  pc 0000d3c0  /system/lib/libc.so (pthread_create+240)
I/DEBUG   (   80): 
I/DEBUG   (   80): stack:
I/DEBUG   (   80):          4ad52bf0  03df4597  
I/DEBUG   (   80):          4ad52bf4  00000000  
I/DEBUG   (   80):          4ad52bf8  00000000  
I/DEBUG   (   80):          4ad52bfc  80000000  
I/DEBUG   (   80):          4ad52c00  00000000  
I/DEBUG   (   80):          4ad52c04  00000000  
I/DEBUG   (   80):          4ad52c08  00000000  
I/DEBUG   (   80):          4ad52c0c  00000000  
I/DEBUG   (   80):          4ad52c10  00000000  
I/DEBUG   (   80):          4ad52c14  00000000  
I/DEBUG   (   80):          4ad52c18  03df44d7  
I/DEBUG   (   80):          4ad52c1c  00000000  
I/DEBUG   (   80):          4ad52c20  41341bad  /system/lib/libmcp.so
I/DEBUG   (   80):          4ad52c24  00000000  
I/DEBUG   (   80):          4ad52c28  42a99a20  [heap]
I/DEBUG   (   80):          4ad52c2c  42a9dadc  [heap]
I/DEBUG   (   80):     #00  4ad52c30  00000006  
I/DEBUG   (   80):          4ad52c34  00000016  
I/DEBUG   (   80):          4ad52c38  0000031e  
I/DEBUG   (   80):          4ad52c3c  000000bd  
I/DEBUG   (   80):          4ad52c40  000000bd  
I/DEBUG   (   80):          4ad52c44  41135075  /system/lib/libc.so (pthread_kill+52)
I/DEBUG   (   80):     #01  4ad52c48  00000006  
I/DEBUG   (   80):          4ad52c4c  00000000  
I/DEBUG   (   80):          4ad52c50  a35aaaaf  
I/DEBUG   (   80):          4ad52c54  41135289  /system/lib/libc.so (raise+14)
I/DEBUG   (   80):     #02  4ad52c58  4ad52c64  
I/DEBUG   (   80):          4ad52c5c  41133fbf  /system/lib/libc.so
I/DEBUG   (   80): 
I/DEBUG   (   80): memory near fp:
I/DEBUG   (   80):     427dfca8 00000000 00000000 00000000 00000039  
I/DEBUG   (   80):     427dfcb8 ffffffff 00000000 00000048 0000004b  
I/DEBUG   (   80):     427dfcc8 495a6318 00000160 00000000 00000000  
I/DEBUG   (   80):     427dfcd8 00000000 00000000 04b8b5d4 00000000  
I/DEBUG   (   80):     427dfce8 00000000 00000000 00000000 00000000  
I/DEBUG   (   80):     427dfcf8 00000000 00000039 ffffffff 42203a98  
I/DEBUG   (   80):     427dfd08 00000048 0000015b 427dfd08 427dfd08


    2） crash时，请注意 bracktrace 后面的打印信息就是crash时代码的位置，第29行 00022020就是最后一次crash的位置，可以使用objdump命令反编译出源代码以便查找导致crash的源代码位置，objdump命令取决于所使用的toolchain（下面是一种linux环境下反编译的命令情况）。

./prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/bin/arm-eabi-objdump -S out/dvb > dvb_map.txt

 

    3）成功生成dvb_map.txt之后，打开该文件

	if( dTempRet == SFS_FILE_TRUE )
	{
		//diag_printf("[Rd] copy file data to RAM\n");
		dTempRet = SFS_ReadFileFull(dFile, pSect->sect_ram_anchor, pSect->sect_ram_size, &dErrNo);
		
		if(dTempRet != SFS_FILE_SUCCESS)
   2200e:	b117      	cbz	r7, 22016 <NVM_Init_Section_DMem+0x66>
		{
			close(dFile);
   22010:	f7e7 ef18 	blx	9e44 <close@plt>
   22014:	e00e      	b.n	22034 <NVM_Init_Section_DMem+0x84>
			dRet = NVM_FAIL;
			goto nvm_init_sect_dmem_fail;
		}
		
		close(dFile);
   22016:	f7e7 ef16 	blx	9e44 <close@plt>
		
		if(u8NvmCreateFile){//BRAD: to indicate that system setting file is created
   2201a:	4912      	ldr	r1, [pc, #72]	; (22064 <NVM_Init_Section_DMem+0xb4>)
   2201c:	4479      	add	r1, pc
   2201e:	780c      	ldrb	r4, [r1, #0]
   22020:	b194      	cbz	r4, 22048 <NVM_Init_Section_DMem+0x98>
			dRet = NVM_WARN_FLASH_EMPTY;
			u8NvmCreateFile = 0;
   22022:	700f      	strb	r7, [r1, #0]
		}
		
		close(dFile);
		
		if(u8NvmCreateFile){//BRAD: to indicate that system setting file is created
			dRet = NVM_WARN_FLASH_EMPTY;
   22024:	2402      	movs	r4, #2
   22026:	e00f      	b.n	22048 <NVM_Init_Section_DMem+0x98>
	pSect = (FLASH_SECTION_STRUCT *)get_sect_object(sect_id);
	
	//Check Layout


    对比源代码就可以找到原因（本例是因为操作了空指针所致）

 

    4）某些情况下查看具体的crash时会比较困难，这个时候可以借用addr2line命令将crash源代码具体文件和行数印出来（同样，此命令不同的toolchain会有所差别）。

prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/bin/arm-eabi-addr2line -f -e out/dvb 22020

    输入命令后会打印出类似下面的语句：


../libs/dvb_db/rw_nvmem.c:791


 

 

北半球校尉
关注
  • 4
    点赞
  • 踩
  • 22
    收藏
    觉得还不错? 一键收藏
  • 4
    评论
专栏目录
android 应用崩溃日志分析,安卓如何获取APP的崩溃日志
weixin_32155269的博客
05-26 1206
码字辛苦！转载请注明出处！安卓APP一旦发生任何报错，就会停止运行，这是令许多开发者头疼的问题，很多情况下，一些隐性BUG在测试部门通过，而在上架之后发生小面积崩溃，这时候的报错因为没有日志，导致BUG无从查起。那么，只能通过用户反馈消耗大量的人力和时间去复现它吗？其实只要在Application中插入一小段代码，就可以把完整的错误日志全部捕捉出来：//记录崩溃信息final Thread.Unc...
Android native crash 日志分析
riskychengallesgut的专栏
09-20 1371
NDK的常见异常 NDK编译生成的.so文件作为程序的一部分，在运行发生异常时同样会造成程序崩溃。不同于Java代码异常造成的程序崩溃，在NDK的异常发生时，程序在Android设备上都会立即退出，即通常所说的闪退，而不会弹出“程序xxx无响应，是否立即关闭”之类的提示框。 NDK是使用C/ Cpp来进行开发的，熟悉C/Cpp的程序员都知道，指针和内存管理是最重要也是最容易出问题的地方，稍有不慎就...
安卓稳定性之crash详解
最新发布
似霰的博客
07-03 1098
安卓稳定性之crash详解
Android crash 日志捕获
dfqin的专栏
09-05 8276
为了对已发布程序进行跟踪，通常会对程序的行为做一些记录并上传到server，一般会记录用户行为已方便更好的发进设计流程和记录程序crash日志，以便在后续版本中改正程序的错误，看了些文章也做了几个Demo,把自己的理解简单写一下。 1. 给线程设置一个自己的异常处理函数（Thread.setDefaultUncaughtExceptionHandler(MyHandler))。 这个方
android app崩溃日志收集以及上传
weixin_34055910的博客
09-05 236
源代码获取请到github：https://github.com/DrJia/AndroidLogCollector 已经做成sdk的形式，源代码已公开，源代码看不懂的请自行google。 假设想定制适应自己app的sdk请自行fork。 AndroidLogCollector android app崩溃日志收集sdk 1.0 作者：贾博士...
Android 获取crash日志工具类
11-27
一个Android可获取运行crash日志的工具类，使用简单方便，直接调用捕获全局crash日志信息，并写入文件到本地，方便查阅
Android crash 日志
10-18
Android crash 文件。用于分析 force close ，快速定位 bug。
crashlog:Android 应用程序崩溃日志保存到文件
07-05
当 crashlog 将 libcrashlog.so 动态加载到应用程序中时，它会在应用程序指定的目录中创建一个崩溃日志文件。 ##edit $vi local.properties sdk.dir=<your>ndk.dir=<your>NDKBUILD=ndk-build (linux, mac) or ndk-...
Android crash log分析工具
08-24
一个linux下面分析Android崩溃日志(crash log)的工具。把崩溃的日志信息(带I/DEBUG标记)复制到xx文件中，用编辑器编辑工具中Android编译的符号(symbol)所在的位置，我的是在309行"SYMBOLS_DIR = './out/target/...
Android 本地日志记录
04-25
例如，可以有一个`logCrash()`方法用于记录异常，`logDeviceInfo()`方法用于记录设备信息，以及`logCustomMessage()`方法用于手动添加自定义日志。这个工具类还应该包含对日志文件的管理和清理逻辑。 总的来说，...
android崩溃日志收集
07-20
android崩溃日志收集
Android中处理崩溃异常和记录日志
09-09
Android中处理崩溃异常和记录日志
Android代码-CrashMonitor 监听程序崩溃日志
08-06
MNCrashMonitor MNCrashMonitor 监听程序崩溃日志,直接页面展示崩溃日志列表,调试方便,测试人员可以随时给程序猿查看日志详情,可以动态添加日志内容,手机直接查看日志内容可以分享,复制,生成长截图，高亮显示。 截图 如何添加 Gradle添加： 1.在Project的build.gradle中添加仓库地址 allprojects { repositories { ... maven { url "https://jitpack.io" } } } 2.在app目录下的build.gradle中添加依赖 dependencies { (support 包版本随意) compile 'com.android.support:appcompat-v7:26.1.0' compile 'com.android.support:recyclerview-v7:26.1.0' compil
Android的Crash日志记录
Millet
01-20 992
android的crash日志记录
Android Crash日志收集
half_bottle的博客
09-21 2973
概述在Android应用的开发过程中，总会遇到应用程序Crash。在编码阶段，设备连接到PC，可以在Android Studio的Logcat中可以查看Crash的信息。但是很明显，靠这种方式收集Crash日志修改bug，实在是太不靠谱，一旦APP发布测试甚至生产环境，如果没有一个Crash日志的反馈，那么将会是一个噩梦，所以本文的目的： 实现自定义的UncaughtExceptionHandler
Android Crash 案例分析
2401_84538135的博客
04-28 1039
我们搜集整理过这几年字节跳动，以及腾讯，阿里，华为，小米等公司的面试题，把面试的要求和技术点梳理成一份大而全的“ Android架构师”面试 Xmind（实际上比预期多花了不少精力），包含知识脉络 + 分支细节。我们搜集整理过这几年字节跳动，以及腾讯，阿里，华为，小米等公司的面试题，把面试的要求和技术点梳理成一份大而全的“ Android架构师”面试 Xmind（实际上比预期多花了不少精力），包含知识脉络 + 分支细节。建议先制定学习计划，根据学习计划把知识点关联起来，形成一个系统化的知识体系。
Android 崩溃日志记录
9624
02-01 315
2、 解决办法： 这是GooglePlay Services方面的一个bug，在修复之前，可以通过将此添加到AndroidManifest.xml内部<application>标签： <uses-library android:name="org.apache.http.legacy" android:required="false" /> ...
安卓应用crash日志的获取
dayuzhuangzhi的博客
04-10 4462
安卓系统的应用免不了crash，或者是应用本身的问题，或者安卓设备的问题，或者安卓系统本身也有bug，那么，把crash的记录在日志，并通过日志回传或者本地获取crash并进行分析，就能更方便的，更有效的分析问题，解决问题 笔者所知的方法大概有三种： 第一种：市面上现有的加固服务方大多提供这个服务，只要把应用上传，平台会自动收集crash日志用于分析，不过前提是要有这些平台的账号（比如友盟）
分析 Android crash 步骤
04-07
1. 收集崩溃日志：在发生崩溃后，Android 系统会自动收集相关的崩溃日志。可以通过 Android Studio 或者其他工具获取该日志，以便分析崩溃原因。 2. 分析崩溃日志：崩溃日志包含了很多信息，包括崩溃堆栈、设备信息、应用信息等。需要仔细分析崩溃日志，查找出崩溃原因。 3. 确认崩溃原因：根据崩溃日志中的信息，确定崩溃原因。可能是代码逻辑错误、内存溢出、线程问题等。 4. 解决崩溃原因：根据确定的崩溃原因，修复代码中的问题。可能需要修改代码逻辑、优化内存使用、修复线程问题等。 5. 测试修复后的应用：修复完崩溃问题后，需要进行测试，确保应用在各种情况下都能正常运行。 6. 发布修复版本：修复完崩溃问题并经过测试后，发布修复版本给用户。
评论 4
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值