Question

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

我现在正在遵循的步骤。

放入xcode配置设备并发布。
构建 - ＆gt;建立和存档。
转到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

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

感谢苏雷什

Answer 1

我也看到了这一点。

我最好的猜测是抛出一个异常，并在＃5或＃6帧中被捕获。当尝试重建原始堆栈跟踪并调用abort（）时，出现了严重错误。

如果是这种情况，真正的堆栈跟踪就会丢失，您可能不得不在调试器中重现问题以查看真正的堆栈跟踪。

Answer 2

修改

它象征着你的代码 - 你正确地做了一切。你可以告诉因为它说main.m：14告诉你堆栈跟踪在main.m的第14行

您无法看到其他内容的原因是因为它不是您的代码:) Apple库是为您编译的 - 您只需将它们链接到您的应用程序即可。它不能告诉你崩溃的线路，因为你没有代码！

这告诉你崩溃发生在苹果代码的深处，这对你来说不是好消息。你需要在XCode中运行它时发生这种崩溃，这样你就可以确切地看到发生了什么。

在我的脑海中，您是否已在链接框架列表中包含libgcc_s？

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

让我感到震惊的是它不仅需要构建相同的代码，它必须与应用程序上安装的完全相同。重建还不够好。

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

NS我还没有使用归档应用程序 - 听起来你做的是正确的事情，但我认为只有Apple了解才会有某种魔力:)我也喜欢在我的版本控制中拥有所有东西而且我不喜欢对XCode中的档案知之甚少，以便对它感到满意。虽然这可能意味着我应该学习它们是如何工作的！

Answer 3

分析崩溃报告的步骤：

1.复制已发送到appstore的.app文件，发布时创建的.dSYM文件，崩溃报告从APPLE接收到文件夹。

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

3.atos -arch armv7 -o''/'＆lt; d.sYY filename这里＆gt;' 。内存位置应该是应用程序根据报告崩溃的位置。

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

这会显示导致崩溃的确切行，方法名称。

Ex：[classname functionName：]; -510

由于

象征着iPad应用程序崩溃报告

3 个答案: