为什么我的崩溃报告没有符号化？

Question

我正在使用 Xcode 4.3.1。崩溃发生在我的设备上，因此我连接该设备并打开组织者，进入我的设备日志，找到崩溃报告，以下是其内容：

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread:  0

Last Exception Backtrace:
0   CoreFoundation                  0x3514488f __exceptionPreprocess + 163
1   libobjc.A.dylib                 0x3656b259 objc_exception_throw + 33
2   CoreFoundation                  0x35144789 +[NSException raise:format:] + 1
3   CoreFoundation                  0x351447ab +[NSException raise:format:] + 35
4   CoreFoundation                  0x350b168b -[__NSCFDictionary setObject:forKey:] + 235
5   myapp                           0x0015b4a7 0xe8000 + 472231
6   myapp                           0x0018add1 0xe8000 + 667089
7   myapp                           0x0013cd5b 0xe8000 + 347483
8   Foundation                      0x30ffb60d __NSFireTimer + 145
9   CoreFoundation                  0x35118a33 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 15
10  CoreFoundation                  0x35118699 __CFRunLoopDoTimer + 365
11  CoreFoundation                  0x3511726f __CFRunLoopRun + 1207
12  CoreFoundation                  0x3509a4a5 CFRunLoopRunSpecific + 301
13  CoreFoundation                  0x3509a36d CFRunLoopRunInMode + 105
14  GraphicsServices                0x36396439 GSEventRunModal + 137
15  UIKit                           0x32190e7d UIApplicationMain + 1081
16  myapp                           0x000f6aff 0xe8000 + 60159
17  myapp                           0x000e9370 0xe8000 + 4976


Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x34f3832c __pthread_kill + 8
1   libsystem_c.dylib               0x36e34208 pthread_kill + 48
2   libsystem_c.dylib               0x36e2d298 abort + 88
3   libc++abi.dylib                 0x30af9f64 abort_message + 40
4   libc++abi.dylib                 0x30af7346 _ZL17default_terminatev + 18
5   libobjc.A.dylib                 0x3656b350 _objc_terminate + 140
6   libc++abi.dylib                 0x30af73be _ZL19safe_handler_callerPFvvE + 70
7   libc++abi.dylib                 0x30af744a std::terminate() + 14
8   libc++abi.dylib                 0x30af881e __cxa_rethrow + 82
9   libobjc.A.dylib                 0x3656b2a2 objc_exception_rethrow + 6
10  CoreFoundation                  0x3509a506 CFRunLoopRunSpecific + 398
11  CoreFoundation                  0x3509a366 CFRunLoopRunInMode + 98
12  GraphicsServices                0x36396432 GSEventRunModal + 130
13  UIKit                           0x32190e76 UIApplicationMain + 1074
14  myapp                           0x000f6af8 0xe8000 + 60152
15  myapp                           0x000e9368 0xe8000 + 4968

我以为Xcode会自动处理符号化崩溃报告？为什么我没有得到任何行数或方法？为什么我的异常代码是0x00000000？

我尝试了这里找到的方法，但当我输入任何内存地址时，输出只是相同的内存地址。这是我可以从崩溃日志中获取的最多信息，还是出了问题？

- Snowman

---

你尝试过使用atos运行崩溃报告吗？ - lottscarson

是的，我尝试了上面链接中提到的方法，也就是使用atos方法，但是无论我在atos -arch armv7 -o 'myapp.app'/'myapp' MEMORY ADDRESS之后输入什么内存地址，它都只会记录下我输入的内存地址，并将其作为输出。因此，这里的输出将是MEMORY ADDRESS。 - Snowman

另外一件事 - 今天早上发生了最后一次崩溃，我更改了几行代码（界面相关），然后进行了构建。我通常不会存档或其他操作，只是构建。因此，我拥有的崩溃日志来自以前的构建（尽管没有太多更改）。如果我不使用存档选项，这可能是原因吗？ - Snowman

是的，这就是原因。符号化只适用于特定的构建版本。即使重新构建完全相同的源代码也不行。 - Steven Fisher

我也遇到了同样的问题。@maq，你找到任何解决方法了吗？ - Suran

Answer 1

希望这能帮助到有相同问题的人。对我来说有效的方法是在存档目录中运行以下命令（看起来像是 /Users/my_user/Library/Developer/Xcode/Archives/2012-09-24，所以首先要进入该目录）。

mdimport .

之后尝试运行symbolicatecrash脚本。在XCode中，进入组织者，设备日志，并通过右键单击崩溃日志选择“重新符号化日志”。

- ruxy

---

这个对于我的市场上的一个应用程序完美地运行了。太棒了！是什么让你发现它的？ - paiego

Answer 2

为了符号化崩溃报告，您需要该确切构建的dSYM包。我猜这是一个未存档的调试构建，因此dSYM也在下次构建应用程序时被覆盖。这就是为什么组织者无法完全符号化崩溃报告的原因。

您提到的方法只适用于未剥离符号的二进制文件，即使如此，它也不会报告行号！因此，与其针对应用程序二进制文件使用它，不如使用dSYM。也许您很幸运，新的dSYM仍然具有一些有用的信息。

崩溃本身可能将NSDictionary值设置为例如nil键。

- Kerni

---

幸运的是，对于我来说，4.3.2 Xcode 版本中的日志已经带有行号和没有当前构建归档，同时在 Debug 配置中设置 Strip Debug Symbols During Copy 为 NO。 - A-Live

然后，dSYM 文件仍然可以在您的 Mac 上找到。符号化脚本使用 Spotlight 进行搜索。作为可执行文件的一部分的符号不提供行号。从来没有。 - Kerni

我一直无法让它正常工作。我的应用程序名称中包含空格和撇号 - 我不确定为什么苹果允许以这种方式提交（或者为什么我没有想得更好），但我无法访问自己代码的任何调试符号。苹果的（核心数据，UIKit等）都可以正常使用。 - SAHM

Answer 3

我无法通过将崩溃报告拖入组织者->设备->库->设备日志中来获得XCode 4.5.1的符号化。

我也无法像@Kerni上面的帖子那样指定dSYM来获取崩溃的符号化地址。

我已经使用了“atos”，但只有在指定xcarchive文件（实际上是一个目录）中符号文件的全路径时才能使其正常工作。例子：

cd dir_where_the_xcarchive_is
atos -arch armv7 -o myApp\ 9-18-12\ 5.28\ PM.xcarchive/dSYMs/myApp.app.dSYM/Contents/Resources/DWARF/myApp   0x0001943a

- cshavit

Answer 4

关于您的异常代码问题...

Exception Codes: 0x00000000, 0x00000000

... 这篇苹果技术说明 可能会回答你的问题。简而言之，这个崩溃报告不是由标准文档化的崩溃类型生成的。

在崩溃日志的前16行左右，您会看到一行以文本开头，后跟一个或多个十六进制值的行，这些值是特定于处理器的代码，可能会为您提供有关崩溃性质的更多信息。您可以从这些代码中了解应用程序是否由于编程错误（例如，错误的内存访问、异常等）而崩溃，还是由于其他原因而终止，例如：

异常代码0x8badf00d表示应用程序已被iOS终止，因为看门狗超时发生。应用程序启动、终止或响应系统事件的时间太长。这种情况的一个常见原因是在主线程上进行同步网络操作。异常代码0xbad22222表示VoIP应用程序已被iOS终止，因为它恢复得太频繁。异常代码0xdead10cc表示应用程序已被iOS终止，因为它在后台运行时占用了系统资源（如通讯录数据库）。异常代码0xdeadfa11表示应用程序已被用户强制退出。当用户首先按住开/关按钮直到出现“滑动关闭电源”时，然后按住主按钮时，就会发生强制退出。可以合理地假设用户之所以这样做是因为应用程序变得无响应，但不能保证 - 强制退出适用于任何应用程序。

- paiego

Answer 5

请使用Crashlytics。

它可以即时提供有关实时崩溃报告的通知（通过电子邮件），并提供崩溃发生位置的确切行号。

- bibo bode