[转]IOS 崩溃日志分析
2013-12-27 10:53
337 查看
以下是一个crash log示例：
下面，我们来一起看下上述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：
分析崩溃日志示例
附录2：
这里有一些比较常见的异常码：
1）0x8badf00d 记作“ate bad food”，这个异常一般是因为系统监视器发现超时现象，比如启动或终止超时，亦或者是长时间响应系统时间（event）。
2）0xbad22222 标志VoIP类应用因为频繁启动被终止。
3）0xdead10cc 记作“dead lock”，当应用在后台运行时，由于占用（hold onto）系统资源（比如通讯录数据库），被操作系统终止。
4）0xdeadfa11 记作“deadfall”，标志应用程序可能因为无响应被用户强行终止。
// 1: Process Information Incident Identifier: 30E46451-53FD-4965-896A-457FC11AD05F CrashReporter Key: 5a56599d836c4f867f6eec76afee451bf9ae5f31 Hardware Model: iPhone4,1 Process: Rage Masters [4155] Path: /var/mobile/Applications/A5635B22-F5EF-4CEB-94B6-FE158D885014/Rage Masters.app/Rage Masters Identifier: Rage Masters Version: ??? (???) Code Type: ARM (Native) Parent Process: launchd [1] // 2: Basic Information Date/Time: 2012-10-17 21:39:06.967 -0400 OS Version: iOS 6.0 (10A403) Report Version: 104 // 3: Exception Exception Type: 00000020 Exception Codes: 0x000000008badf00d Highlighted Thread: 0 // 4: Threads backtraces Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0: 0 libsystem_kernel.dylib 0x327f2eb4 mach_msg_trap + 20 1 libsystem_kernel.dylib 0x327f3048 mach_msg + 36 2 CoreFoundation 0x36bd4040 __CFRunLoopServiceMachPort + 124 3 CoreFoundation 0x36bd2d9e __CFRunLoopRun + 878 4 CoreFoundation 0x36b45eb8 CFRunLoopRunSpecific + 352 5 CoreFoundation 0x36b45d44 CFRunLoopRunInMode + 100 6 CFNetwork 0x32ac343e CFURLConnectionSendSynchronousRequest + 330 7 Foundation 0x346e69ba +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 242 8 Rage Masters 0x000d4046 0xd2000 + 8262 Thread 1: 0 libsystem_kernel.dylib 0x32803d98 __workq_kernreturn + 8 1 libsystem_c.dylib 0x3a987cf6 _pthread_workq_return + 14 2 libsystem_c.dylib 0x3a987a12 _pthread_wqthread + 362 3 libsystem_c.dylib 0x3a9878a0 start_wqthread + 4 // 5: Thread state Thread 0 crashed with ARM Thread State (32-bit): r0: 0x00000000 r1: 0x00000000 r2: 0x00000001 r3: 0x39529fc8 r4: 0xffffffff r5: 0x2fd7d301 r6: 0x2fd7d300 r7: 0x2fd7d9d0 r8: 0x2fd7d330 r9: 0x3adbf8a8 r10: 0x2fd7d308 r11: 0x00000032 ip: 0x00000025 sp: 0x2fd7d2ec lr: 0x001bdb25 pc: 0x30301838 cpsr: 0x00000010 // 6: Binary images Binary Images: 0xd2000 - 0xd7fff +Rage Masters armv7 <f37ee6d2c7b334868972e0e9c54f7062> /var/mobile/Applications/A5635B22-F5EF-4CEB-94B6-FE158D885014/Rage Masters.app/Rage Masters 0x2fe41000 - 0x2fe61fff dyld armv7 <75594988728831d98e1f7c4c7b7ca29d> /usr/lib/dyld 0x327f2000 - 0x32808fff libsystem_kernel.dylib armv7 <f167dacec44b3a86a8eee73400ff7a83> /usr/lib/system/libsystem_kernel.dylib 0x328a8000 - 0x328bdfff libresolv.9.dylib armv7 <e79b59a3406f34d9b37f8085955115ce> /usr/lib/libresolv.9.dylib 0x32a70000 - 0x32b35fff CFNetwork armv7 <3e973794a4d13428bb974edcb2027139> /System/Library/Frameworks/CFNetwork.framework/CFNetwork 0x32b7a000 - 0x32cc3fff libicucore.A.dylib armv7 <0253932c1b9038a0849ef73c38e076ca> /usr/lib/libicucore.A.dylib 0x32cc4000 - 0x32cc5fff CoreSurface armv7 <b3f9d4e8dd803a48b88c58a0663d92a3> /System/Library/PrivateFrameworks/CoreSurface.framework/CoreSurface 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”，标志应用程序可能因为无响应被用户强行终止。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 