iOS应用程序崩溃,符号日志不透明

时间:2014-10-10 06:28:44

标签: objective-c xcode swift crash app-store

我相信我正在查看正确的符号化日志,但请告诉我,如果不是这样的话。这是我从苹果公司收到的崩溃日志的摘录,因为在发布时因为崩溃而被拒绝,我完全无法复制。

我安装了一个名为Crashlytics的崩溃报告系统,在应用程序处于审核期间没有收到任何崩溃报告,这让我相信崩溃发生在AppDelegate的didFinishLaunchingWithOptions Crashlytics初始化之前。也就是说,Crashlytics仅在崩溃后重新打开应用程序时发送报告。因此,Apple评论员可能遇到了崩溃,并且没有再次尝试,可能是因为我没有Crashlytics报告。

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread:  0

Last Exception Backtrace:
(0x181f9a084 0x1929ec0e4 0x180819674 0x100091318 0x100084fe4 0x100084098 0x18671d158 0x18671ce68 0x1867d0ee8 0x1869d1da8 0x186791938 0x18671e88c 0x1867906f8 0x10006187c 0x18678e5d0 0x1869a4de8 0x1869a7568 0x1869a5c00 0x18a171640 0x181f52360 0x181f51468 0x181f4fa8c 0x181e7d664 0x18678798c 0x186782984 0x100061c28 0x19305aa08)

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x0000000193172964 __kill + 8
1   Luff                            0x00000001001330dc 0x10005c000 + 880860
2   libsystem_platform.dylib        0x0000000193208958 _sigtramp + 64
3   libsystem_pthread.dylib         0x0000000193211224 pthread_kill + 108
4   libsystem_c.dylib               0x00000001930eab14 abort + 108
5   libc++abi.dylib                 0x00000001921d1414 abort_message + 112
6   libc++abi.dylib                 0x00000001921f0b88 default_terminate_handler() + 300
7   libobjc.A.dylib                 0x00000001929ec3bc _objc_terminate() + 124
8   libc++abi.dylib                 0x00000001921edbb0 std::__terminate(void (*)()) + 12
9   libc++abi.dylib                 0x00000001921ed738 __cxa_rethrow + 140
10  libobjc.A.dylib                 0x00000001929ec290 objc_exception_rethrow + 40
11  CoreFoundation                  0x0000000181e7d710 CFRunLoopRunSpecific + 568
12  UIKit                           0x0000000186787988 -[UIApplication _run] + 548
13  UIKit                           0x0000000186782980 UIApplicationMain + 1484
14  Luff                            0x0000000100061c24 0x10005c000 + 23588
15  libdyld.dylib                   0x000000019305aa04 start + 0

2 个答案:

答案 0 :(得分:1)

你所拥有的并不是完全象征性的。为了使其完全符号化,即第14行和第1行的函数名称,以及最后一个异常回溯,,您需要dSYM文件,这是在构建应用程序时生成的提交并放在与您的应用包相同的文件夹中。如果您使用Xcode的存档功能,我相信dSYM包含在存档中。我说的是第1行和第14行,因为那些是你的应用程序名称(Luff)。

您需要做的是将崩溃报告,dSYM文件和应用程序文件(不是IPA)放在同一个文件夹中(我不确定应用程序文件是否真的需要Xcode进行符号化,因此制作如果它不仅仅与崩溃报告和dSYM一起工作,那确定它就在那里)。然后,将崩溃报告导入Xcode组织器,然后单击"重新符号化#34;。

除非你能以某种方式将报告中的地址映射到符号(函数,方法),否则你现在拥有的内容在没有dSYM的情况下是100%无用的。

此外,崩溃线程的堆栈跟踪不是相关信息的位置。根据经验,我可以告诉你关于堆栈跟踪的一些事情。第14行的符号很可能是你的main()函数。没什么特别的。

1到14之间的行显示了一堆异常重新抛出和捕获,即不是导致崩溃的堆栈跟踪,而是传递异常的堆栈跟踪。既然你提到你有Crashlytics,我打赌第14行就是这样。它说Luff而不是Crashlytics,因为Crashlytics是一个嵌入到你的应用程序中的静态库。出于所有意图和目的,iOS将其视为您应用的另一部分。我说它是Crashlytics的原因是当你捕获崩溃时,导致崩溃的事情(异常,信号等)有时会被重新抛出,它最终会到达你自己的自定义崩溃报告代码。

相关信息位于您上面的Last Exception Backtrace地址中。但要阅读它,必须使用dSYM文件进行符号化。

就像你说的,Crashlytics不是实时的。用户需要重新打开该应用程序。我知道这一切是因为我正在处理我自己的项目,名为 Crashional这是实时,只要有互联网连接。

答案 1 :(得分:0)

您未通过Crashlytics获取报告的一个可能原因是,审核人在首次启动您的应用时可能已禁用该设备上网功能。即使她再次打开它,也不会将崩溃发回Crashlytics。