2. 程式人生 > >Android crash 日誌 分析

Android crash 日誌 分析

阿新 • • 發佈：2019-01-19

      在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 <
 
[email protected]>
   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 <[email protected]>
		
		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

相關推薦

Android crash 日誌 分析

      在Android開發的過程中，有時候需要建立一個純linux的應用程式，當這些程式crash時，如果找不到導致crash的直接原因，問題將很難被修復。本文將介紹一種分析crash問題的方法。     1）以下是crash時串列埠的列印資訊： pid: 96, t

Android ANR日誌分析指南

當你的專案越做越複雜，或者你的使用者達到某個數量級的時候，你的程式碼不小心出現細小的問題，你會收到各種各樣的bug,其中ANR的問題你一定不會陌生。本文將詳細講解ANR的型別、出現的原因、ANR案例詳細分析、經典的案例。 定義 ANR(Application Not Responding) 應用

crash日誌的分析

二進制文件 解決 view -c form array 通過 網絡請求 voip 怎樣獲得crash日誌 怎樣解析crash日誌 怎樣分析crash日誌 1. iOS策略相關 2. 常見錯誤標識 3. 代碼bug 一、怎樣獲得crash

android anr簡介與traces日誌分析方法

一：什麼是ANR ANR:Application Not Responding，即應用無響應 二：ANR的型別 ANR一般有三種類型： 1：KeyDispatchTimeout(5 seconds) --主要型別 按鍵或觸控事件在特定時間內無響應 2：BroadcastTim

iOS通過dSYM檔案分析crash日誌

iOS通過dSYM檔案分析crash日誌 平常在開發的過程中，遇到到了Crash可以很容易的通過Xcode去定位Crash的位置，但是當我們的App釋出以後，遇到閃退就不可以通過Xcode去除錯了。當然現在也有很多產品可以線上分析，例如騰訊的bugly與友盟的錯誤分析。這些分析工具的最基本的地方還是

iOS開發之Crash日誌獲取與分析

當在非除錯狀態下，我們用真機測試app，crash或者說閃退是一件很常見的事，最讓我們開發人員頭疼的是，自己在開發過程中總是不會遇到crash，安裝到別人的裝置，就出現了閃退崩潰現象。這種偶現的、概率比較低的閃退是最令人頭疼。 這時iOS crash log 

iOS日常Debug之Crash日誌檔案分析

好久沒寫部落格了，真的不是忙沒有時間。就是懶！閒話少說，言歸正傳。事件起因，群裡一個朋友說自己的app被拒了，蘋果給的被拒原因是AppStore稽核指南條例2.1，說是app存在崩潰。還附帶上了Crash日誌檔案。看了一眼Crash日誌檔案，徹底懵了！

APP閃退分析及Crash日誌獲取

app 閃退一般抓取mtklog看不出具體原因，即使有aee_exp資料夾產生，使用Logcatview工具也解析不出 具體的db檔案 一、手機crash之後，如果彈出的“應用程式意外停止”的提示如果沒有消失，則可使用以下方法獲取 crash日誌 1、直接連上eclipse

iOS奔潰分析技巧-crash日誌符號化

前言 iOS開發需要不停發版本，開發者要面臨線上各種版本的奔潰日誌(crash log)，解決奔潰問題是移動開發者最日常的工作之一. 在實際的專案開發中，崩潰問題，依賴xcode，依賴於系統記錄的崩潰日誌或錯誤堆疊，在本地開發除錯階段，是沒有問題的。 如果

分析android crash log（記錄未實驗）

2 c/c++, 通常情況下，可以通過segment fault 等錯誤即訊號 SIGSEGV(11) 做出相應處理，即設定SIGSEGV的handler呼叫libc的backtrace，即可列印對於的callback stack；定位問題所在；但在android 中， b

windows常用日誌分析

windows 計算機 用戶 帳戶 查找AD中用戶帳戶鎖定時間及鎖定的計算機。a.打開安全日誌。b.查找eventid 4740,即可查找出被鎖定帳戶和鎖定源。本文出自 “工作備忘錄” 博客，謝絕轉載！windows常用日誌分析

centos7搭建ELK Cluster日誌分析平臺（一）

場景 git centos7 beat images 下載地址 install posit src 應用場景：ELK實際上是三個工具的集合，ElasticSearch + Logstash + Kibana，這三個工具組合形成了一套實用、易用的監控架構， 　　　　　很多公司

centos7搭建ELK Cluster集群日誌分析平臺（四）：簡單測試

-1 簡單測試 logs ima .tar.gz 分析 -c cluster images 續之前安裝好的ELK集群 　　各主機：es-1 ~ es-3 :192.168.1.21/22/23 　　　　　　logstash:　　192.168.1.24 　　　　　　ki

Logwatch日誌分析工具

logwatch日誌監控介紹：Logwatch是使用 Perl 開發的一個日誌分析工具。Logwatch能夠對Linux 的日誌文件進行分析，並自動發送mail給相關處理人員，可定制需求。Logwatch的mail功能是借助宿主系統自帶的mail server 發郵件的，所以系統需安裝mail server

linux下awk日誌分析

linux 接口 記錄 video 文本命令數據分析假設線上倒出的接口訪問日誌有上百行，該日誌的記錄格式如下：/data1/www/logs/archives/170524/170524.v6.weibo.com_10.72.13.113.0.cn.gz:v6.weibo.com 123.12

ELK日誌分析系統 介紹 安裝配置

elkELK日誌分析系統一、ELK介紹 ELK顧名思義：是由Elasticsearch，Logstash 和 Kibana三部分組成的。 其中Elasticsearch 是一個實時的分布式搜索和分析引擎，它可以用於全文搜索，結構化搜索以及分析。它是一個建立在全文搜索引擎 Apache Lucene

P1165 日誌分析

ostream 最大 char 忽略 urn amp namespace 擁有 code 題目描述 M 海運公司最近要對旗下倉庫的貨物進出情況進行統計。目前他們所擁有的唯一記錄就是一個記錄集裝箱進出情況的日誌。該日誌記錄了兩類操作：第一類操作為集裝箱入庫操作，以及該次

開源日誌分析系統ELK平臺搭建部署

logstash 日誌分析系統 elk 開源日誌分析系統ELK平臺搭建部署 一、前言日誌主要包括系統日誌、應用程序日誌和安全日誌。系統運維和開發人員可以通過日誌了解服務器軟硬件信息、檢查配置過程中的錯誤及錯誤發生的原因。經常分析日誌可以了解服務器的負荷，性能安全性，從而及時采取措施糾正錯誤。通常

ELK服務搭建（開源實時日誌分析ELK平臺部署）（低版本—簡單部署）

搜索引擎 應用程序 官方網站 服務器 安全性 elk 開源實時日誌分析ELK平臺部署日誌主要包括系統日誌、應用程序日誌和安全日誌。系統運維和開發人員可以通過日誌了解服務器軟硬件信息、檢查配置過程中的錯誤及錯誤發生的原因。經常分析日誌可以了解服務器的負荷，性能安全性，從而及時采取措施糾正

ELK日誌分析系統搭建配置

elk我們主要用ELK日誌分析系統來分析Nginx訪問日誌，mysql慢查詢日誌，tomcat運行日誌以及系統日誌等。介紹：ELK：ElasticSearch+LogStash+Kibana=ElkStackElasticSearch:存儲、收索、分析（可以用solr替代）LogStash：收集器，輸入，處理