Swift/iOS 崩溃日志不包含行号答案

【问题标题】：Swift/iOS crash log does not contain line numberSwift/iOS 崩溃日志不包含行号
【发布时间】：2019-03-27 18:49:27
【问题描述】：

我正在通过 TestFlight 向测试人员部署构建，但应用程序崩溃了。我无法重现崩溃，因此我试图依靠 Xcode Organizer 中列出的崩溃日志。

不幸的是，这里的崩溃包含一些信息，但没有任何信息可以让我识别导致崩溃的代码行。通常，当我在 Organizer 窗口中单击崩溃时，它会自动显示 Xcode 中导致崩溃的行。

这是原始的崩溃日志，它也不包含行号，只包含发生崩溃的文件和方法。

Thread 0 name:
Thread 0 Crashed:
0   libswiftCore.dylib              0x0000000103154b8c 0x102f64000 + 2034572
1   libswiftCore.dylib              0x0000000103154b8c 0x102f64000 + 2034572
2   libswiftCore.dylib              0x000000010316017c 0x102f64000 + 2081148
3   libswiftCore.dylib              0x0000000103105cfc 0x102f64000 + 1711356
4   libswiftCore.dylib              0x0000000103160984 0x102f64000 + 2083204
5   libswiftCore.dylib              0x00000001030ad2f8 0x102f64000 + 1348344
6   AppName                         0x0000000102c92748 specialized TableViewController.sendSmsMessage(sender:) + 8816 (TableViewController.swift:0)

(TableViewController.swift:0)
7   AppName                         0x0000000102c8c448 @objc TableViewController.CorF(sender:) + 44
8   UIKitCore                       0x00000001ea7a6314 -[UIApplication sendAction:to:from:forEvent:] + 96 (UIApplication.m:4786)
9   UIKitCore                       0x00000001ea233d54 -[UIControl sendAction:to:forEvent:] + 80 (UIControl.m:624)
10  UIKitCore                       0x00000001ea234074 -[UIControl _sendActionsForEvents:withEvent:] + 440 (UIControl.m:707)
11  UIKitCore                       0x00000001ea233074 -[UIControl touchesEnded:withEvent:] + 568 (UIControl.m:461)
12  UIKitCore                       0x00000001ea7dfa6c -[UIWindow _sendTouchesForEvent:] + 2472 (UIWindow.m:2204)
13  UIKitCore                       0x00000001ea7e0cd0 -[UIWindow sendEvent:] + 3156 (UIWindow.m:2453)
14  UIKitCore                       0x00000001ea7bffcc -[UIApplication sendEvent:] + 340 (UIApplication.m:10819)
15  UIKitCore                       0x00000001ea88ee38 __dispatchPreprocessedEventFromEventQueue + 1620 (UIEventDispatcher.m:1678)
16  UIKitCore                       0x00000001ea891830 __handleEventQueueInternal + 4740 (UIEventDispatcher.m:1937)
17  UIKitCore                       0x00000001ea88a320 __handleHIDEventFetcherDrain + 152 (UIEventDispatcher.m:1905)
18  CoreFoundation                  0x00000001bd44a0e0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24 (CFRunLoop.c:1980)
19  CoreFoundation                  0x00000001bd44a060 __CFRunLoopDoSource0 + 88 (CFRunLoop.c:2015)
20  CoreFoundation                  0x00000001bd449944 __CFRunLoopDoSources0 + 176 (CFRunLoop.c:2051)
21  CoreFoundation                  0x00000001bd444810 __CFRunLoopRun + 1040 (CFRunLoop.c:2922)
22  CoreFoundation                  0x00000001bd4440e0 CFRunLoopRunSpecific + 436 (CFRunLoop.c:3247)
23  GraphicsServices                0x00000001bf6bd584 GSEventRunModal + 100 (GSEvent.c:2245)
24  UIKitCore                       0x00000001ea7a4c00 UIApplicationMain + 212 (UIApplication.m:4347)
25  AppName                         0x0000000102c7d0f0 main + 60 (SMS.swift:12)
26  libdyld.dylib                   0x00000001bcf02bb4 start + 4

知道如何确定导致崩溃的线路吗？

编辑：按照@Václav 的建议，我能够让用户向我发送存储在他们设备上的崩溃报告，但它似乎也没有包含太多有用的信息：

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libswiftCore.dylib              0x0000000104e774ec 0x104c8c000 + 2012396
1   libswiftCore.dylib              0x0000000104e774ec 0x104c8c000 + 2012396
2   libswiftCore.dylib              0x0000000104e828cc 0x104c8c000 + 2058444
3   libswiftCore.dylib              0x0000000104e28fd4 0x104c8c000 + 1691604
4   libswiftCore.dylib              0x0000000104e830cc 0x104c8c000 + 2060492
5   libswiftCore.dylib              0x0000000104dd142c 0x104c8c000 + 1332268
6   AppName                         0x00000001047fa948 0x1047e0000 + 108872
7   AppName                         0x00000001047f4784 0x1047e0000 + 83844
8   UIKitCore                       0x00000001e6fe6314 0x1e66fc000 + 9347860
9   UIKitCore                       0x00000001e6a73d54 0x1e66fc000 + 3636564
10  UIKitCore                       0x00000001e6a74074 0x1e66fc000 + 3637364
11  UIKitCore                       0x00000001e6a73074 0x1e66fc000 + 3633268
12  UIKitCore                       0x00000001e6bfaaf0 0x1e66fc000 + 5237488
13  UIKitCore                       0x00000001e6bf57ec 0x1e66fc000 + 5216236
14  UIKitCore                       0x00000001e6bf52cc 0x1e66fc000 + 5214924
15  UIKitCore                       0x00000001e6bf509c 0x1e66fc000 + 5214364
16  UIKitCore                       0x00000001e7020cb4 0x1e66fc000 + 9587892
17  UIKitCore                       0x00000001e6ffffcc 0x1e66fc000 + 9453516
18  UIKitCore                       0x00000001e70cee38 0x1e66fc000 + 10300984
19  UIKitCore                       0x00000001e70d1830 0x1e66fc000 + 10311728
20  UIKitCore                       0x00000001e70ca320 0x1e66fc000 + 10281760
21  CoreFoundation                  0x00000001b9c8a0e0 0x1b9bdd000 + 708832
22  CoreFoundation                  0x00000001b9c8a060 0x1b9bdd000 + 708704
23  CoreFoundation                  0x00000001b9c89944 0x1b9bdd000 + 706884
24  CoreFoundation                  0x00000001b9c84810 0x1b9bdd000 + 686096
25  CoreFoundation                  0x00000001b9c840e0 0x1b9bdd000 + 684256
26  GraphicsServices                0x00000001bbefd584 0x1bbef2000 + 46468
27  UIKitCore                       0x00000001e6fe4c00 0x1e66fc000 + 9341952
28  AppName                         0x00000001047e5860 0x1047e0000 + 22624
29  libdyld.dylib                   0x00000001b9742bb4 0x1b9742000 + 2996

【问题讨论】：

那么，您的应用在通过 TestFlight 安装后会在真实设备上崩溃？当您通过 XCode 构建和安装它时，您无法在 XCode Simulator 上重现它？只是为了澄清。
查看stackoverflow.com/questions/53872700/…。第 0 行很可能意味着编译器已为您生成代码，并且与源代码中的实际行不对应。由于那里有specialized，我倾向于相信这里就是这种情况。
在偏移量0x102c92748 上设置断点并单步执行...
我觉得不行，你可以发Debug给TF。正如你所说，我几乎 100% 确定 TF 强制释放。您可以在设置为英国语言环境的真实设备上构建它，并尝试在连接到 XCode 并打开All Exceptions 断点时使其崩溃。
@Václav，这是个好主意。让我试试。

标签： ios swift xcode

【解决方案1】：

这个问题有几个不同的元素，所以让我试着分解一下。

为什么我会看到第 0 行？

在实际生成最终编译的二进制文件之前，Swift 编译器会生成大量代码。在这种情况下，line 0 是编译器告诉您它在编译 TableViewController.swift 时生成了代码的方式，但该代码与原始源代码中的特定行不对应。

因为这里有一个specialized 函数，所以我更倾向于相信这是编译器生成的代码。这通常意味着编译器正在使用泛型类型。

我对 Apple 以这种方式传达这一事件感到失望，但我们无能为力。我的理解是DWARF可以描述这种事情。但是，要么 Apple 不使用此工具，要么不编写崩溃报告，或者很可能两者兼而有之。

您可以通过使用atos 或dwarfdump 来符号化地址0x0000000102c92748 来验证此行为。我敢打赌，它会输出完全相同的内容 - 第 0 行。过去我曾使用dwarfdump 在此处查看是否在 dSYM 中编码了更多信息，但我什么也没找到。不过那是几年前的事了，所以情况可能已经改变了。

第 3 方崩溃记者可以提供帮助吗？

它们都使用 dSYM 进行符号化，因此它们不能拥有比该文件中包含的更多信息。无论如何，这可能值得一试，但我怀疑你会在第 0 行的任何地方获得任何东西。

但是，他们可能能够符号化来自libswiftCore.dylib 的帧，这可能会很有帮助。

为什么会发生这种崩溃？

这是百万美元的问题。

我想查看实际的崩溃详细信息。我的猜测是这是一条非法指令，因为您在 swift 运行时库中崩溃了。可能发生的情况是运行时因某种非法状态而跳闸。展开 nil Optional 肯定是它。也可能是越界Range 操作。我认为越界数组索引也可能以这种方式失败，但我不知道，我不确定。

我要做的就是仔细看看TableViewController.sendSmsMessage(sender:) 中发生了什么。密切注意上面列出的内容，特别是如果它与任何通用标准库函数交互。

我也会尝试象征那些libswiftCore.dylib 帧。同样，您可以为此使用atos，只需将其指向库本身并使用加载地址即可。我不确定 Xcode 内部将 Swift 库保存在哪里，因此您可以只使用与您的应用程序捆绑的 lib 副本。

祝你好运！

【讨论】：

谢谢@Mattie！我已经在 SO 上尝试了一些经常建议的东西，就像你描述的那样——符号化、atos 等。我仍然得到同样的东西：第 0 行。一个新的发展是我能够让用户发送给我一份崩溃报告，但它似乎同样没用。
绝对同意做一些侦探工作来隔离问题而不是依赖崩溃报告可能是最容易的。一个问题是崩溃报告者似乎给我的唯一信息是发生崩溃的函数，但它是一个巨大的函数。我开始认为实现此目的的唯一方法是将其分解为许多较小的函数，以便更具体地指示崩溃的触发位置。
我知道获得行号会很好，但是您无法做到。编译器没有在任何地方对这些信息进行编码——它已经消失了:(你有没有尝试符号化那些 libswiftCore.dylib 帧？另一方面，那些可以给你一个线索。至于重构那个函数，一定要去做！
我试试看。我将接受您的回答，因为它解释了这里发生的事情。感谢大家的帮助！
很高兴能帮上忙！