象征性的 iPad 应用程序崩溃报告答案

【问题标题】：symbolicating iPad app crash reports象征性的 iPad 应用程序崩溃报告
【发布时间】：2010-12-21 12:09:30
【问题描述】：

在这里，我对 iPad 开发和 Objective-c 有点陌生。我在阅读设备日志时遇到问题。当我浏览日志时，人们说我已经构建并存档并将该构建用于设备。这样下次当您将设备连接到您的机器时，设备日志将自动符号化崩溃日志。但事实并非如此。

我现在正在遵循的步骤。

放xcode配置设备并发布。
构建 -> 构建和存档。
进入 Build 文件夹，将二进制文件拖放到 Itunes 图标上并选择替换。
测试完成后，重新连接ipad，进入管理器窗口，选择设备，点击设备日志。
这仅显示符号...没有任何关于崩溃位置的线索。

例如：崩溃报告

Thread 0 Crashed:
0   libSystem.B.dylib               0x30d7c2d4 __kill + 8
1   libSystem.B.dylib               0x30d7c2c4 kill + 4
2   libSystem.B.dylib               0x30d7c2b6 raise + 10
3   libSystem.B.dylib               0x30d90d72 abort + 50
4   libSystem.B.dylib               0x30d7e980 __assert_rtn + 152
5   libgcc_s.1.dylib                0x307e8b4e _Unwind_SjLj_Resume + 26
6   CoreFoundation                  0x35801d50 CFRunLoopRunSpecific + 432
7   CoreFoundation                  0x35801b88 CFRunLoopRunInMode + 52
8   GraphicsServices                0x320c84a4 GSEventRunModal + 108
9   GraphicsServices                0x320c8550 GSEventRun + 56
10  UIKit                           0x341dc322 -[UIApplication _run] + 406
11  UIKit                           0x341d9e8c UIApplicationMain + 664
12  My EF                           0x00002c84 main (main.m:14)
13  My EF                           0x00002c4c start + 32

如果我做错了什么，请告诉我。

谢谢肯定的

【问题讨论】：

标签： iphone objective-c ipad

【解决方案1】：

我也看到了。

我最好的猜测是抛出异常并在 #5 或 #6 帧中捕获。然后当它试图重建原始堆栈跟踪并调用 abort() 时出现了严重错误。

如果是这种情况，则真正的堆栈跟踪丢失了，您可能必须在调试器中重现问题才能看到真正的堆栈跟踪。

【讨论】：

【解决方案2】：

编辑

它象征着你的代码——你做的一切都是正确的。你可以知道，因为它说 main.m:14 告诉你堆栈跟踪在 main.m 的第 14 行

您看不到任何其他内容的原因是因为它不是您的代码 :) Apple 库是为您编译的 - 您只需将它们链接到您的应用程序中。它不能告诉你因为你没有代码而崩溃的行！

这告诉您崩溃发生在苹果代码深处的某个地方，这对您来说不是好消息。你需要在 XCode 中运行它时让这个崩溃发生，这样你才能确切地看到发生了什么。

没想到，您是否将 libgcc_s 包含在您的链接框架列表中？

是的，这是一个棘手的问题。

让我感到困惑的是，它不仅必须是相同代码的构建，还必须与应用上安装的完全相同的构建。重建还不够好。

为了解决这个问题，我使用了版本控制（特别是 git）。每次我将应用程序的一个版本分发给人们进行测试时，我都会将构建文件夹复制到发布/目录中。然后我标记它（例如 release_2010_12_10_showcase），所以如果他们回来时崩溃，我可以问他们什么时候给他们应用程序并检查正确的构建版本。这意味着我在他们的应用程序上拥有来自构建的符号，并且我在 XCode 中的代码与他们正在运行的代码完全相同，因此我可以看到崩溃发生的位置并修复它:) 然后，使用 git 的魔力，我可以将我的更改合并到我的最新代码中:)

NS 我还没有使用存档应用程序 - 听起来你在做正确的事情，但我认为有某种只有 Apple 才能理解的魔法发生了 :) 我也喜欢在我的版本控制中包含所有内容，我不知道对 XCode 中的档案知之甚少，无法适应它。虽然这可能意味着我应该学习它们的工作原理！

【讨论】：

您好院长感谢您的回复。我得到了它。它具有象征意义。以及 libgcc_s 是什么。您能否告诉我它的作用以及它如何以任何方式帮助我..？谢谢suresh
我不知道 libgcc_s 是什么 - 您的应用程序中似乎需要它。要将其添加为框架，请右键单击项目中的框架组并选择“添加”->“现有框架”。您应该能够在该列表中找到 libgcc_s.1.dylib。选择它，看看应用程序是否运行不崩溃？
你如何最终将上面给出的堆栈跟踪与代码相关联？我已经在 git 中标记了代码，但我不确定我应该如何获得相关的行号（特别是考虑到它似乎没有在我的应用程序中运行除了 main.m 之外的任何东西 - 一切else 编译在苹果/gnu 框架中）

【解决方案3】：

分析崩溃报告的步骤：

1.将推送到应用商店的发布.app文件、发布时创建的.dSYM文件和APPLE收到的崩溃报告复制到一个文件夹中。

2.打开终端应用程序并转到上面创建的文件夹（使用CD命令）。

3.atos -arch armv7 -o ''/'<.dsym filename here>' 。根据报告，内存位置应该是应用程序崩溃的位置。

例如：atos -arch armv7 -o 'app name.app'/'app name' 0x0003b508

这将向您显示导致崩溃的确切行和方法名称。

例如：[类名函数名：]； -510

谢谢

【讨论】：