iPhone真机测试Crash信息分析

最新推荐文章于 2024-07-03 16:40:03 发布

CoderLiLe

最新推荐文章于 2024-07-03 16:40:03 发布

阅读量1.2k

点赞数

分类专栏： iOS 文章标签： iphone

本文链接：https://blog.youkuaiyun.com/CoderLiLe/article/details/51075220

版权

iOS 专栏收录该内容

3 篇文章

订阅专栏

项目在模拟器上一直没有问题，可是到真机上突然发生了Crash，瞬间整个人都感觉不好了。导出了机子上的Crash报告，咋一看天书一般，经过在http://stackoverflow.com上面查找终于搞明白了原因。先附上Crash报告：

// 1: Process Information
Incident Identifier: CCBEE2BC-E2FB-4E43-83D5-FBD6B87F2ADE
CrashReporter Key:   703cffef5d700f1eaa0d3921fb8ef142d4780cf9
Hardware Model:      iPhone8,1
Process:             NiuNiu [5639]
Path:                /private/var/mobile/Containers/Bundle/Application/A37341B1-FC88-4E49-A102-017A7AE5218C/NiuNiu.app/NiuNiu
Identifier:          com.sdbean.NiuNiuManagers
Version:             2.9.1 (1.3)
Code Type:           ARM-64 (Native)
Parent Process:      launchd [1]

// 2: Basic Information
Date/Time:           2016-03-21 08:30:02.02 +0800
Launch Time:         2016-03-19 07:54:25.25 +0800
OS Version:          iOS 9.2.1 (13D15)
Report Version:      105

// 3: Exception
Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Triggered by Thread:  0

Filtered syslog:
None found

Last Exception Backtrace:
(0x181375900 0x1809e3f80 0x1812641a8 0x181264040 0x1000d0dc0 0x1000d07f0 0x180dc9630 0x180dc95f0 0x180dcecf8 0x18132cbb0 0x18132aa18 0x181259680 0x182768088 0x1860d0d90 0x1000ec1b0 0x180dfa8b8)

Global Trace Buffer (reverse chronological seconds):
1.273655     CFNetwork                  0x00000001819ef104 TCP Conn 0x126ca8d20 complete. fd: 8, err: 0

// 4: Threads backtraces
Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x0000000180f18140 0x180efc000 + 115008
1   libsystem_pthread.dylib         0x0000000180fe0ef8 0x180fdc000 + 20216
2   libsystem_c.dylib               0x0000000180e89dac 0x180e28000 + 400812

Thread 1 name:  Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0   libsystem_kernel.dylib          0x0000000180f194fc 0x180efc000 + 120060
1   libdispatch.dylib               0x0000000180ddc94c 0x180dc8000 + 84300
2   libdispatch.dylib               0x0000000180dcb7bc 0x180dc8000 + 14268

// 此处省略

// 5: Thread state
Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000000   x1: 0x0000000000000000   x2: 0x0000000000000000   x3: 0x00000001256111a1
    x4: 0x00000001809daba2   x5: 0x000000016fd95940   x6: 0x000000000000006e   x7: 0x00000000000000e0

// 6: Binary images
Binary Images:
0x100068000 - 0x1001fbfff NiuNiu arm64  <136fc60898023e57934bf98a2da74a2e> /var/mobile/Containers/Bundle/Application/A37341B1-FC88-4E49-A102-017A7AE5218C/NiuNiu.app/NiuNiu
0x120020000 - 0x12004ffff dyld arm64  <9e98992ceed735e2ac4784cb28efe7c1> /usr/lib/dyld
0x180964000 - 0x180965fff libSystem.B.dylib arm64  <c4cd04b37e5f34698856a9384aefff40> /usr/lib/libSystem.B.dylib
0x180968000 - 0x1809bbfff libc++.1.dylib arm64  <d430d0ad16893b76bbc52468f65d5906> /usr/lib/libc++.1.dylib
0x1809bc000 - 0x1809dbfff libc++abi.dylib arm64

现在做一下分析：

（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）0x8badf00d  记作“ate bad food”，这个异常一般是因为系统监视器发现超时现象，比如启动或终止超时，亦或者是长时间响应系统时间（event）。
2）0xbad22222  标志VoIP类应用因为频繁启动被终止。
3）0xdead10cc  记作“dead lock”，当应用在后台运行时，由于占用（hold onto）系统资源（比如通讯录数据库），被操作系统终止。
4）0xdeadfa11  记作“deadfall”，标志应用程序可能因为无响应被用户强行终止。