[转]IOS 崩溃日志分析

以下是一个crash log示例：

 

 1 // 1: Process Information
 2 Incident Identifier: 30E46451-53FD-4965-896A-457FC11AD05F
 3 CrashReporter Key:   5a56599d836c4f867f6eec76afee451bf9ae5f31
 4 Hardware Model:      iPhone4,1
 5 Process:         Rage Masters [4155]
 6 Path:            /var/mobile/Applications/A5635B22-F5EF-4CEB-94B6-FE158D885014/Rage Masters.app/Rage Masters
 7 Identifier:      Rage Masters
 8 Version:         ??? (???)
 9 Code Type:       ARM (Native)
10 Parent Process:  launchd [1]
11  
12 // 2: Basic Information
13 Date/Time:       2012-10-17 21:39:06.967 -0400
14 OS Version:      iOS 6.0 (10A403)
15 Report Version:  104
16  
17 // 3: Exception
18 Exception Type:  00000020
19 Exception Codes: 0x000000008badf00d
20 Highlighted Thread:  0
21  
22 // 4: Threads backtraces
23 Thread 0 name:  Dispatch queue: com.apple.main-thread
24 Thread 0:
25 0   libsystem_kernel.dylib            0x327f2eb4 mach_msg_trap + 20
26 1   libsystem_kernel.dylib            0x327f3048 mach_msg + 36
27 2   CoreFoundation                    0x36bd4040 __CFRunLoopServiceMachPort + 124
28 3   CoreFoundation                    0x36bd2d9e __CFRunLoopRun + 878
29 4   CoreFoundation                    0x36b45eb8 CFRunLoopRunSpecific + 352
30 5   CoreFoundation                    0x36b45d44 CFRunLoopRunInMode + 100
31 6   CFNetwork                         0x32ac343e CFURLConnectionSendSynchronousRequest + 330
32 7   Foundation                        0x346e69ba +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 242
33 8   Rage Masters                      0x000d4046 0xd2000 + 8262
34  
35 Thread 1:
36 0   libsystem_kernel.dylib            0x32803d98 __workq_kernreturn + 8
37 1   libsystem_c.dylib                 0x3a987cf6 _pthread_workq_return + 14
38 2   libsystem_c.dylib                 0x3a987a12 _pthread_wqthread + 362
39 3   libsystem_c.dylib                 0x3a9878a0 start_wqthread + 4
40  
41 // 5: Thread state
42 Thread 0 crashed with ARM Thread State (32-bit):
43     r0: 0x00000000    r1: 0x00000000      r2: 0x00000001      r3: 0x39529fc8
44     r4: 0xffffffff    r5: 0x2fd7d301      r6: 0x2fd7d300      r7: 0x2fd7d9d0
45     r8: 0x2fd7d330    r9: 0x3adbf8a8     r10: 0x2fd7d308     r11: 0x00000032
46     ip: 0x00000025    sp: 0x2fd7d2ec      lr: 0x001bdb25      pc: 0x30301838
47   cpsr: 0x00000010
48  
49 // 6: Binary images
50 Binary Images:
51 0xd2000 -    0xd7fff +Rage Masters armv7  <f37ee6d2c7b334868972e0e9c54f7062> /var/mobile/Applications/A5635B22-F5EF-4CEB-94B6-FE158D885014/Rage Masters.app/Rage Masters
52 0x2fe41000 - 0x2fe61fff  dyld armv7  <75594988728831d98e1f7c4c7b7ca29d> /usr/lib/dyld
53 0x327f2000 - 0x32808fff  libsystem_kernel.dylib armv7  <f167dacec44b3a86a8eee73400ff7a83> /usr/lib/system/libsystem_kernel.dylib
54 0x328a8000 - 0x328bdfff  libresolv.9.dylib armv7  <e79b59a3406f34d9b37f8085955115ce> /usr/lib/libresolv.9.dylib
55 0x32a70000 - 0x32b35fff  CFNetwork armv7  <3e973794a4d13428bb974edcb2027139> /System/Library/Frameworks/CFNetwork.framework/CFNetwork
56 0x32b7a000 - 0x32cc3fff  libicucore.A.dylib armv7  <0253932c1b9038a0849ef73c38e076ca> /usr/lib/libicucore.A.dylib
57 0x32cc4000 - 0x32cc5fff  CoreSurface armv7  <b3f9d4e8dd803a48b88c58a0663d92a3> /System/Library/PrivateFrameworks/CoreSurface.framework/CoreSurface
58 0x32f65000 - 0x32f8afff  OpenCL armv7  <f7706501012430fc94ed99006419fba9> /System/Library/PrivateFrameworks/OpenCL.framework/OpenCL
 

下面，我们来一起看下上述crash log每个section的含义：

（1）Process Information

        这部分给出了进程crash后的部分信息

  • Incident Identifier crash报告的唯一标识
  • CrashReporter Key crash报告映射到Device Identifier的唯一键值（key）。表面上看上去没有任何含义，但实际上给我们提供了一个有用信息，假如我们所获得的大量crash log拥有同样的Crashreport Key，一定程度上说明这个crash问题并不是普遍存在，也许只是对一些特定的设备存在。
  • Hardware Model 当前设备类型。假如我们所获得的大量crash log拥有同样的Hardware Model，很大程度上可以说明app在该类设备上运行存在适配的问题。
  • Process app的名字。

（2）Basic Information

        这部分给出了crash的一些基本信息：crash发生的时间，当前设备上操作系统的版本等。如果多数crash log拥有相同的iOS版本号，一定程度上说明app对于该版本iOS系统存在适配问题。

（3）Exception

        这部分给出了crash的异常类型，异常错误码和抛出异常的线程。

（4）Threads backtraces

        这部分给出了crash时app所有线程的堆栈记录，列出crash时函数调用堆栈。比如：

 

 

        以上，包含四列：编号，调用的库或工程的名称，函数指针（被调用的方法的地址），文件地址+行编号

 

（5）Thread state

        这部分给出了crash时寄存器中的值。事实上，堆栈记录已经提供了类似的信息。

（6）Binary images

        这部分列出了crahs时加载的所有文件。

 

接下来，我们在看一个内存警告的crash log

 

可以看到，第一部分和之前的crash log内容类似，这里对其他部分的含义作简要的说明：

  • Free pages  代表可用内存，每个page近似为4KB，故，上面的log里面显示的可用内存为3,872 KB (or 3.9 MB)
  • Purgeable pages  代表可清除和重用的内存，上面的log显示为0KB
  • Largest process  crash时占用内存最多的应用
  • Processes  列出进程列表及crash时进程的内存占用情况，包含进程名字，进程唯一标识符，进程使用的page数，app状态（一般情况下引起crash的app拥有frontmost状态）

附录1：

        分析崩溃日志示例

         atos -o YourApp.app.dSYM/Contents/Resources/DWARF/YourApp 0x00062867

 

附录2：

 

        这里有一些比较常见的异常码：

        1）0x8badf00d  记作“ate bad food”，这个异常一般是因为系统监视器发现超时现象，比如启动或终止超时，亦或者是长时间响应系统时间（event）。

        2）0xbad22222  标志VoIP类应用因为频繁启动被终止。

        3）0xdead10cc  记作“dead lock”，当应用在后台运行时，由于占用（hold onto）系统资源（比如通讯录数据库），被操作系统终止。

        4）0xdeadfa11  记作“deadfall”，标志应用程序可能因为无响应被用户强行终止。

posted @ 2013-12-27 10:53  U_探索  阅读(6597)  评论(0)  编辑  收藏  举报