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 with iTunes

可以看到,2种方式都不太靠谱,所以现实的方法还是使用第三方框架,比如Crashlytics之类的。在app崩溃的时候,会自动采集crash log

符号化

拿到crash log以后,还要解决怎么读的问题。原始的crash log是不可读的,内容类似这样:

Last Exception Backtrace:

(0x313b1e83 0x3ba4d6c7 0x312e7d95 0xcef95 0xce843 0x7c6d1 0x3bf320c3 0x3bf377d9 0x3bf379c5 0x3c061dff 0x3c061cc4)

Thread 0:

0   libsystem_kernel.dylib         0x3bfeaa84 0x3bfea000 + 2692

1   libsystem_kernel.dylib         0x3bfea87d 0x3bfea000 + 2173

2   CoreFoundation                 0x3137c555 0x312dd000 + 652629

3   CoreFoundation                 0x3137acbb 0x312dd000 + 646331

4   CoreFoundation                 0x312e546d 0x312dd000 + 33901

5   CoreFoundation                 0x312e524f 0x312dd000 + 33359

6   GraphicsServices               0x35fe62e7 0x35fdf000 + 29415

7   UIKit                         0x33b9a841 0x33b2b000 + 456769

这样的一份日志,即使拿到了也几乎没有意义,对定位问题没有帮助,所以需要将crash log做符号化

一般来说,任何app的crash log在xcode中都能部分符号化,也就是UIKit,CoreFoundation这种系统级的库,但是要想真正得到完全符号化的crash log,需要满足2个条件:

1、有app的二进制包

2、有编译此二进制包时得到的dSYM文件

只要是曾经编译过该app的机器,应该都满足这个条件。然后把拿到的.ips或.crash文件导入到xcode,就会自动符号化了,完全符号化以后,crash log就可读了:

Last Exception Backtrace:

0   CoreFoundation                 0x183cba950 __exceptionPreprocess + 132

1   libobjc.A.dylib               0x1905701fc objc_exception_throw + 60

2   CoreFoundation                 0x183bbc218 -[__NSArrayI objectAtIndex:] + 204

3   TestNotification               0x100029cfc -[MainViewController clicked1] (MainViewController.m:42)

4   UIKit                         0x186cb90c8 -[UIApplication sendAction:to:from:forEvent:] + 100

5   UIKit                         0x186cb905c -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 24

6   UIKit                         0x186ca2538 -[UIControl _sendActionsForEvents:withEvent:] + 376

7   UIKit                         0x186cb8a5c -[UIControl touchesEnded:withEvent:] + 584

8   UIKit                         0x186cb86f0 -[UIWindow _sendTouchesForEvent:] + 692

9   UIKit                         0x186cb3388 -[UIWindow sendEvent:] + 1172

10  UIKit                         0x186c84b68 -[UIApplication sendEvent:] + 256

11  UIKit                         0x186c82c58 _UIApplicationHandleEventQueue + 8500

12  CoreFoundation                 0x183c7b044 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24

13  CoreFoundation                 0x183c7a3a0 __CFRunLoopDoSources0 + 256

14  CoreFoundation                 0x183c78638 __CFRunLoopRun + 632

15  CoreFoundation                 0x183bb96d0 CFRunLoopRunSpecific + 452

16  GraphicsServices               0x189845c0c GSEventRunModal + 168

17  UIKit                         0x186ceafdc UIApplicationMain + 1156

18  TestNotification               0x100029990 main (main.m:16)

19  libdyld.dylib                 0x190b63aa0 start + 4

Thread 0 Crashed:

0   libsystem_kernel.dylib         0x0000000190c5e58c __pthread_kill + 8

1   libsystem_c.dylib             0x0000000190bf2804 abort + 108

2   libc++abi.dylib               0x000000018fe18990 abort_message + 84

3   libc++abi.dylib               0x000000018fe35c28 default_terminate_handler() + 296

4   libobjc.A.dylib               0x00000001905704d0 _objc_terminate() + 124

5   libc++abi.dylib               0x000000018fe33164 std::__terminate(void (*)()) + 12

6   libc++abi.dylib               0x000000018fe32d38 __cxa_rethrow + 140

7   libobjc.A.dylib               0x00000001905703a4 objc_exception_rethrow + 40

8   CoreFoundation                 0x0000000183bb9748 CFRunLoopRunSpecific + 572

9   GraphicsServices               0x0000000189845c08 GSEventRunModal + 164

10  UIKit                         0x0000000186ceafd8 UIApplicationMain + 1152

11  TestNotification               0x000000010002998c main (main.m:16)

12  libdyld.dylib                 0x0000000190b63a9c start + 0

line3可以很清楚地看出,崩溃发生在MainViewController的42行,关于dSYM的介绍,详见这篇文章:crash log

所以最好的办法,还是使用第三方框架。以Crashlytics为例,它会要求在xcode的编译过程中集成一个脚本,这个脚本的作用大致上是把二进制包和dSYM发送到Crashlytics的网站上,这样当Crashlytics拿到crash log以后,也就可以进行完全的符号化了

ios crash log获取和符号化

时间: 2024-09-30 21:11:26

ios crash log获取和符号化的相关文章

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 分析(三)

如果不知道怎么获取CrashLog 或者 Crash Log符号化请看这两篇文章 如何获取真机Crash Log 文件 如何符号化Crash Log文件 打开Crash Log 会看到如下的信息: Incident Identifier: AF4F2C83-8F68-47EF-B5AA-F16B067B5DF4 CrashReporter Key:   5670de85ee1f0f3c904891536e81ec086ed4b35b Hardware Model:      iPhone8,1

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

别用symbolicatecrash来解析crash Log了by 风之枫

今天突然发现了一个解析iOS crash log的好方法,忍不住来分享一下. 相信每个做iOS开发的TX都应该不会对symbolicatecrash陌生,我们第一次遇到真机上产生的崩溃日志时,在网上搜到的大部分教程都告诉我们说要用symbolicatecrash来解析crash log,我信了,所以相当长一段时间内,我都是用这个工具来解析crash log的. 每次都去敲命令来解析crash log本身就是一件很蛋疼的事情,但这还不是麻烦的,最麻烦的是用symbolicatecrash还经常遇到

IOS崩溃日志解析(crash log)

IOS的应用程序少不了crash,互联网统计分析工具友盟有一项目错误分析的功能,专门用于应用程序崩溃日志统计,最近研究友盟上统计到的崩溃日志,在此对崩溃日志做一个简单的总结. IOS崩溃日志分类: 一.低内存崩溃:IOS设备检测到低内存时,虚拟内存系统发出通知请求应用释放内存.这些通知发送到所有正在运行的应用和进程,试图收回一些内存.如果内存使用依然居高不下,系统将会终止后台线程以缓解内存压力.如果可用内存足够,应用将能够继续运行而不会产生崩溃报告.否则,应用将被iOS终止,并产生低内存崩溃报告

iOS Crash日志符号化

1.为什么要符号化: IOS程序在真机运行程序出现crash状况时,机器会自动产生log文件,它包含了在程序crash之前的运行逻辑,分析carsh文件,有效的解决程序在真机上的问题,保证程序良好的稳定性,但是这个crash文件多数是显示出现问题的地址和一些系统的消息,无法查看程序中对应的崩溃地点.所以需要符号化转化为我们熟悉的代码方便定位问题. xxx.crash的原日志: 0 libsystem_kernel.dylib 0x32a50dfc __pthread_kill + 8 1 lib