iOS Crash Log 分析(三)

如果不知道怎么获取CrashLog 或者 Crash Log符号化请看这两篇文章

如何获取真机Crash Log 文件

如何符号化Crash Log文件

打开Crash Log 会看到如下的信息:

Incident Identifier: AF4F2C83-8F68-47EF-B5AA-F16B067B5DF4

CrashReporter Key:   5670de85ee1f0f3c904891536e81ec086ed4b35b

Hardware Model:      iPhone8,1

Process:             kidneyUser [896]

Path:                /private/var/containers/Bundle/Application/48C71AA1-EB99-49B1-ABD7-2903DBA8E394/kidneyUser.app/kidneyUser

Identifier:          kidneyDiseaseHospitalUser

Version:             1 (1.0)

Code Type:           ARM-64 (Native)

Parent Process:      launchd [1]

Date/Time:           2016-05-05 10:45:43.43 +0800

Launch Time:         2016-05-05 10:42:07.07 +0800

OS Version:          iOS 9.3.1 (13E238)

Report Version:      105

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:

0   CoreFoundation                    0x181aeee38 __exceptionPreprocess + 124

1   libobjc.A.dylib                   0x181153f80 objc_exception_throw + 56

2   CoreData                          0x18393ab44 -[NSManagedObjectModel initWithContentsOfURL:] + 856

3   kidneyUser                        0x1002b81d8 0x1000d8000 + 1966552

4   kidneyUser                        0x1002b82dc 0x1000d8000 + 1966812

5   kidneyUser                        0x1002b86a0 0x1000d8000 + 1967776

6   kidneyUser                        0x1002b87cc 0x1000d8000 + 1968076

7   kidneyUser                        0x1002b8024 0x1000d8000 + 1966116

8   UIKit                             0x186cc9128 -[UIApplication _terminateWithStatus:] + 280

9   UIKit                             0x186ee7f08 __102-[UIApplication _handleApplicationDeactivationWithScene:shouldForceExit:transitionContext:completion:]_block_invoke2017 + 796

10  UIKit                             0x186eeafd8 _runAfterCACommitDeferredBlocks + 292

11  UIKit                             0x186ef8990 _cleanUpAfterCAFlushAndRunDeferredBlocks + 92

12  UIKit                             0x186c2a4a4 _afterCACommitHandler + 96

13  CoreFoundation                    0x181aa47b0 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32

14  CoreFoundation                    0x181aa2554 __CFRunLoopDoObservers + 372

15  CoreFoundation                    0x181aa2984 __CFRunLoopRun + 928

16  CoreFoundation                    0x1819ccd10 CFRunLoopRunSpecific + 384

17  GraphicsServices                  0x1832b4088 GSEventRunModal + 180

18  UIKit                             0x186ca1f70 UIApplicationMain + 204

19  kidneyUser                        0x1002c71e8 0x1000d8000 + 2028008

20  libdyld.dylib                     0x18156a8b8 start + 4

Global Trace Buffer (reverse chronological seconds):

2.434148     AppleJPEG                     0x000000018354ea88 [0x12e203600] Releasing session

Thread 0 name:  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:

0   libsystem_kernel.dylib            0x000000018168811c __pthread_kill + 8

1   libsystem_pthread.dylib           0x0000000181754ef8 pthread_kill + 112

2   libsystem_c.dylib                 0x00000001815f9dac abort + 140

3   libc++abi.dylib                   0x000000018112d3f4 __cxa_bad_cast + 0

4   libc++abi.dylib                   0x0000000181149e98 default_unexpected_handler() + 0

5   libobjc.A.dylib                   0x0000000181154248 _objc_terminate() + 124

6   libc++abi.dylib                   0x0000000181146f44 std::__terminate(void (*)()) + 16

7   libc++abi.dylib                   0x0000000181146b10 __cxa_rethrow + 144

8   libobjc.A.dylib                   0x0000000181154120 objc_exception_rethrow + 44

9   CoreFoundation                    0x00000001819ccdb8 CFRunLoopRunSpecific + 552

10  GraphicsServices                  0x00000001832b4088 GSEventRunModal + 180

11  UIKit                             0x0000000186ca1f70 UIApplicationMain + 204

12  kidneyUser                        0x00000001002c71e8 0x1000d8000 + 2028008

13  libdyld.dylib                     0x000000018156a8b8 start + 4

以上就是Crash Log 文件的信息(设备的信息, crash信息,异常信息, 线程信息)

1. 设备信息

Incident Identifier: AF4F2C83-8F68-47EF-B5AA-F16B067B5DF4   // crash的ID

CrashReporter Key:   5670de85ee1f0f3c904891536e81ec086ed4b35b  
// crash 的设备ID

Hardware Model:      iPhone8,1   // 手机的型号 (iPhone8,1代表iPhone6s  8,2 代表iPhone6s Plus)

Process:             kidneyUser [896]   // App的名称 (该App的进程ID)

Path:                /private/var/containers/Bundle/Application/48C71AA1-EB99-49B1-ABD7-2903DBA8E394/kidneyUser.app/kidneyUser         // APP 的位置 路径

Identifier:          kidneyDiseaseHospitalUser // bundle ID

Version:             1 (1.0)   // APP的版本号

Code Type:           ARM-64 (Native) // app的应用架构

Parent Process:      launchd [1]

Date/Time:           2016-05-05 10:45:43.43 +0800      // crash发生的时间

Launch Time:         2016-05-05 10:42:07.07 +0800    // 进入应用的时间

OS Version:          iOS 9.3.1 (13E238)    // iOS系统的版本

Report Version:      105

如果产品上线之后, 回收集大量的Crash Log日志文件, 可以对Crash文件里面的手机型号,版本号, 手机型号, iOS系统版本,进行分类, 可以获得更多的信息, 更好的解决bug甚至未知的bug具体原因, 做更好的测试

2.异常信息

Exception Type:  EXC_CRASH (SIGABRT)   // 异常的类型

Exception Codes: 0x0000000000000000, 0x0000000000000000  // 异常出错的代码

Exception Note:  EXC_CORPSE_NOTIFY  // 异常通知

Triggered by Thread:  0 // 异常发生的线程(0代表主线程, 其他为主线程)

补充常见的Exception Codes代码类型

Exception Codes:   常见代码有以下几种

0x8badf00d错误码：Watchdog超时，意为“ate bad food”。

0xdeadfa11错误码：用户强制退出，意为“dead fall”。

0xbaaaaaad错误码：用户按住Home键和音量键，获取当前内存状态，不代表崩溃。

0xbad22222错误码：VoIP应用（因为太频繁？）被iOS干掉。

0xc00010ff错误码：因为太烫了被干掉，意为“cool off”。

0xdead10cc错误码：因为在后台时仍然占据系统资源（比如通讯录）被干掉，意为“dead lock”

补充常见的Exception Type异常类型的信息:

1.EXC_BAD_ACCESS：此类型是最常见的crash, 通常用于访问了不该访问的内存导致的,一般     EXC_BAD_ACCESS后面的()还会带有补充信息

SIGSEGV:
通常由于重复释放对象导致, 一般在ARC以后很少见到

SIGABRT: 收到Abort信号退出, 通常Foundtion库中的容器为了保护状态正常会做一些检测, 例如插入nil到数据中等会遇到此类错误.

SEGV(Segmentation Violation): 代表无效内存地址, 比如空指针, 未初始化指针, 栈溢出等.

SIGBUS:
总栈错误, 与SIGSEGV不同的是, SIGSEGV访问的是无效的地址, 而SIGBUS访问的是有效的地址, 但是总栈访问异常(如地址对齐问题)

SIGILL: 尝试执行非法的指令, 可能不被识别或者没有权限

SIGFPE: 数学计算相关问题, 比如除零操作

SIGIPIPE: 管道另一端没有进程接手数据

2. EXC_BAD_INSTRUCTION：此类异常通常由于线程执行非法指令导致

3. EXC_ARITHMETIC：除零错误会抛出此类异常

Last Exception Backtrace: 最后异常回溯, 一般根据这个代码就能找到具体的crash问题

下面截取的是微信的crash blog

Thread 0 name:  Dispatch queue: com.apple.main-thread

Thread 0:

0   libsystem_kernel.dylib            0x000000018223ff24 __psynch_cvwait + 8

1   libsystem_pthread.dylib           0x000000018230ad20 _pthread_cond_wait + 704

2   Foundation                        0x0000000182f9fdf0 -[NSCondition waitUntilDate:] + 344

3   Foundation                        0x0000000182f9ce34 -[NSConditionLock lockWhenCondition:beforeDate:] + 256

4   UIKit                             0x000000018781dbc4 -[UIKeyboardTaskQueue waitUntilAllTasksAreFinished] + 196

5   UIKit                             0x0000000187c05878 -[UIKeyboardImpl setKeyboardInputMode:userInitiated:] + 112

6   UIKit                             0x0000000187c0de44 -[UIKeyboardImpl recomputeActiveInputModesWithExtensions:] + 336

7   UIKit                             0x000000018781e8f0 -[UIKeyboardImpl setDelegate:force:] + 2292

8   UIKit                             0x0000000187817eb0 -[UIPeripheralHost(UIKitInternal) _reloadInputViewsForResponder:] + 1180

9   UIKit                             0x00000001878179e4 -[UIResponder(UIResponderInputViewAdditions) reloadInputViews] + 80

10  UIKit                             0x0000000187879670 -[UIResponder becomeFirstResponder] + 600

11  UIKit                             0x0000000187879a1c -[UIView(Hierarchy) becomeFirstResponder] + 148

12  UIKit                             0x0000000187900b34 -[UITextField becomeFirstResponder] + 64

13  UIKit                             0x00000001879b1fe4 -[UITextInteractionAssistant(UITextInteractionAssistant_Internal) setFirstResponderIfNecessary] + 256

14  UIKit                             0x00000001879b1498 -

我们可以看到发生Crash的线程的Crash调用栈, 从上到下分别代表调用顺序, 最上面的一个表示抛出异常的位置, 一次往下可以看到API调用顺序, 上图的信息表明本次Crash出现在[NSCondition waitUntilDate:]这个方法中(后面加的数值 我猜应该是地址偏移量O(∩_∩)O) 大概可以找到crash的具体原因(某个文件中的某个方法),
这样问题就浮出水面了, 方便产品上线后版本迭代, 修改BUG.

最后有一个大神的分析很详细大神分析Crash Log 很详细

时间： 2024-11-09 19:37:32

iOS Crash Log 分析(三)的相关文章

IOS Crash Log 分析

上架AppStroe 被打回来了,原因是: Your app crashed on iPad running iOS 11.3.1 connected to an IPv6 network when we tapped on profile image. We have attached detailed crash logs to help troubleshoot this issue. 崩溃日志 一.Crash文件结构 当程序运行Crash的时候,系统会把运行的最后时刻的运行信息记录下来,

IOS crash log分析

此处不讨论具体的如何根据.dsym文件解析crash log的方式. 一.一般的崩溃 1.违反苹果的政策:启动.恢复.暂停或退出超时; 用户强制退出: 低内存退出:MemoryWarning; 2.程序中有bug 二.崩溃解析说明 1.MemoryWarning的崩溃比较特别,没有任何trace,标志性信息即某一条trace后面有“jettisoned”. 解决方法: 可用Allocations.Leaks Instruments 或VM Tracker Instrument来帮助检查.另外,解

在Xcode6下IOS Crash Log分析文一

1.导出Log文件 将手机连接到mac上,打开Xcode,window-Devices-This Device,就能刷新出所有本机crash时留下的日志文件,选择你的crash文件,右键-Export Log到User/crash目录下 2.获取app和dsYM文件 Xcode-window-organizer-Archives就能看到我们曾经archive过的所有文件,找到crash对应的archive文件,右键-show in finder-右键-显示包内容,将dSYMs/xxxx.dSYM

IOS Crash log分析(转)

说明一下,symbolicatecrash是一个可以独立使用的错误日志分析工具. 虽然iPhone连着Xcode的时候可以直接查看设备Logs,但是更多的崩溃情况是发生在我们在分发了ipa之后(无论是测试还是上架).因此,如果我们有幸从用户手中拿到了Logs,那么此时symbolicatecrash就可以大显神威了,它能够将错误日志转化成我们可读的形式. symbolicatecrash不出意外,也是用到了Mapping方式来替换标记. (1)在桌面创建一个Crash文件夹 (2)找到symbo

iOS crash log 解析

iOS开发中,经常遇到App在开发及测试时不会有问题,但是装在别人的设备中会出现各种不定时的莫名的 crash,因为iOS设备会保存应用的大部分的 crash Log,所以可以通过 crash Log 来定位 crash 原因. 一. 获取iOS设备上的 crash log 1. 将iOS设备连接到电脑上,打开 Xcode -> Organizer -> Devices,找到该台设备,在 Device logs 中找到 crash log(后缀为 .crash 的 log 文件),将其导出即可

ios crash log获取和符号化

获取crash log 如果不借助第三方框架,要收集ios app的crash log是一件很困难的事情.有2个办法: 第一个办法是要求用户打开"诊断与用量"中的自动发送,然后如果APP崩溃了,ios会弹出提示框,用户确认之后,crash log会自动发送到苹果后台,然后用开发者账号登陆上去,可以拿到crash log 第二个办法是将device,同步到iTunes之后,再从pc上拿到crash log,再发送 详细步骤见: how to get crash log syncing w

ios crash文件分析

http://www.cnblogs.com/yingkong1987/p/3157692.html http://blog.sina.com.cn/s/blog_a573f7990101gi4k.html http://stackoverflow.com/questions/3609084/ipad-app-works-on-most-devices-gets-exc-crash-sigabrt-on-some 新建一个专门的目录进行解析处理,如: /crash 把对应的.app和.dSYM文

ios crash 日志分析

以下内容来自网络 https://coderwall.com/p/ezdcmg/symbolicating-an-ios-crash-log-without-the-original-dsym-file http://blog.csdn.net/jasonblog/article/details/19031517#0-tsina-1-77321-397232819ff9a47a7b7e80a40613cfe1 http://www.cocoachina.com/industry/20140514

iOS App Crash原理分析

预备知识:OS X系统分析 1.内核XNU是Darwin的核心,也是整个OS X的核心.XNU本身由以下几个组件构成: Mach微核心 BSD层 libKern I/O Kit 此外,内核是模块化的,允许根据需要动态加载插件形式的内核扩展. 2.Mach:XNU的核心,Mach仅能处理操作系统最基本的职责: 进程和线程抽象. 虚拟内存管理 任务调度 进程间通信和消息传递机制(例如:NSMachPort) 3.所以OS X是在Mach内核的基础上构建的,苹果不鼓励直接只用Mach的API,但是Ma