iOS Crash文件分析

一．iOS crashs一般有如下四种：

• Application crash

• Low memory

• Watchdog timeout

• User force-quit

当前我们的ERead程序遇到了前三种core问题。只有Application crash文件才会提供有用的crash堆栈。

Low memory 主要是程序申请不到可用的内存或者剩余内存不足以支持程序运行而产生的crash.

WatchDog timeout 是程序100%暂用cpu超过10s而产生的crash文件。 User force-quit :暂时还没搞清什么情况下会出现。 

二.如何找到crash文件  

iPhone真机上Crash文件的存储路径为：/var/mobile/Library/Logs/CrashReporter 可以通过PhoneView（mac下），91助手（windows下）读取。 

需要保存***.app.dSYM 符号文件（生产版本的时候和***.app同在build目录） 

获取crash文件：

可以直接连接到itunes，itunes会自动把crash文件同步到pc机，在pc上的目录是：~/Library/Logs/CrashReporter/MobileDevice下面。 同步完成后也可以在XCode的Window的Organizer下面，找到相应Device设备，选择DeviceLog标签，找到相应的crash文件。

三． crash文件介绍 

一般如果是内存过低引起的core问题，crash文件会命名为“LowMemory-2011-06-05-044757.log”的格式，其中的日期为同步到pc时的日期 

如果是其他原因引起的core问题，crash文件会命名为“ETReader_2011-04-12-103850_adminmato-iPad.crash”的格式，其中日期为同步到pc的时间，adminmato-iPad指的是当前所有设备所取的名称 一般情况下，我们只看第二种的crash文件，第一种crash文件是和手机内存大小及程序占用内存有关，一般情况下不做处理

四．通过crash文件定位问题

（针对Application crash，其他crash文件无法提供有效信息） 把***.app.dSYM和crash文件放到同一个目录下

执行命令：

1	symbolicatecrash ***.crash ***.app.dSYM | less

就会得到符号化好的crash文件。如果crash是通过itunes同步到pc机，并且在Organizer中查看的话，那么看到的crash是已经由xcode调用symbolicatecrash 命令符号化好了的（右键Reveal Log in Finder可以得到该crash文件）。

crash例子文件如下：

view source

print ?

01	Incident Identifier: 2664D48C-C1D7-43EC-8E89-01D27EE2E7E0

02	CrashReporter Key:

03	ae8ae7a933bd6670313190b38a0b7a9cd6fb5329

04	Hardware Model:

05

iPhone2,1

06	Process:     ETReader [3445]

07

Path:

08	/var/mobile/Applications/C7C76450-4A8D-4CFE-B662-923523CFADB1/ETReader.app/ETReader

09	Identifier:    ETReader

10

Version:

11

??? (???)

12	Code Type:  ARM (Native)

13	Parent Process:  punchd [1]

14	Date/Time:   2011-04-14 15:21:24.064 +0800

15	OS Version:  iPhone OS 4.2.1 (8C148a)

16	Report Version:  104

17	Exception Type: EXC_BAD_ACCESS (SIGBUS)

18	Exception Codes: KERN_PROTECTION_FAILURE at 0×00000004

19	Crashed Thread: 0

20	Thread 0 Crashed:

21	0  ETReader                0x0009dcc8 0×1000 + 642248

22	1  ETReader                0x0003baf2 0×1000 + 240370

23	2   Foundation             0x31cd861c 0x31cc4000 + 83484

24	3   CoreFoundation     0x3145711c 0×31430000 + 160028

25	4   CoreFoundation      0x31456dbc 0×31430000 + 159164

26	5   Foundation              0x31cc7d1c 0x31cc4000 + 15644

27	6   Foundation              0x31cd123a 0x31cc4000 + 53818

28	7   UIKit                         0x338ff904 0x3389e000 + 399620

29	8   UIKit                         0x338fdbb8 0x3389e000 + 392120

30	9   UIKit                         0x338a27a6 0x3389e000 + 18342

31	Binary Images:

32	0×1000 -

33	0xd2fff +ETReader armv7

34	<e2cd3c3a2d5d5cecc3ceec0792b50309> /var/mobile/Applications/C7C76450-4A8D-4CFE-B662-923523CFADB1/ETReader.app/ETReader

35	0x1f5000 -

36	0x1f5fff +MobileSubstrate.dylib armv6

37	<93c7cc820225e9453a9f93d3b21a25fa> /Library/MobileSubstrate/MobileSubstrate.dylib

38	0×225000 -

39	0x226fff +SubstrateLoader.dylib armv6

40	<073e8f5afee21e96e513e796622bfd6f> /Library/Frameworks/CydiaSubstrate.framework/Libraries/SubstrateLoader.dylib

41	0x22a000 -

42

0x22bfff

43	dns.so armv7

44	<fcefecb2d5e095ba88127eec3af57ec0> /usr/lib/info/dns.so

45	0×246000 -

46	0x258fff +SBPandaHome.dylib armv6

47	<8bfff4a460e806aca029a0b989419225> /Library/MobileSubstrate/DynamicLibraries/SBPandaHome.dylib

48	0×264000 -

49

0x267fff

50	libsubstrate.dylib armv6

51	<9ad52a9dd3b8e54ae1b0a0e5fc58c7a2> /usr/lib/libsubstrate.dylib

发现有针对ETReader的堆栈地址： 

1	ETReader                      0x0009dcc8 0×1000 + 642248

2	ETReader                      0x0003baf2 0×1000 + 240370

 但是如何把地址映射到相应的文件对应的函数呢。 需要在命令行执行如下命令：

1	dwarftdump –lookup 0x0009dcc8 –arch armv7 ***.app.dSYM

此处到底是armv7还是armv6，在 Binary Images附近可以查看体系结构（红色大字体标注）。

执行完该命令会在控制台上打印出一堆定位信息，好啦后面我就不啰嗦了，可以自己分析啦。