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

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

ios swift xcode

Swift/iOS崩溃日志不包含行号,ios,swift,xcode,Ios,Swift,Xcode,我正在通过TestFlight向测试人员部署一个构建，应用程序正在崩溃。我无法在我的终端复制崩溃，因此我试图依赖Xcode Organizer中列出的崩溃日志不幸的是，这里的崩溃包含一些信息，但没有任何信息允许我识别导致崩溃的代码行。通常，当我在“管理器”窗口中单击崩溃时，它会自动显示导致崩溃的Xcode中的行这是原始崩溃日志，它也不包含行号，只包含发生崩溃的文件和方法 Thread 0 name: Thread 0 Crashed: 0 libswiftCore.dylib

我正在通过TestFlight向测试人员部署一个构建，应用程序正在崩溃。我无法在我的终端复制崩溃，因此我试图依赖Xcode 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

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

为什么我看到第0行？

Swift编译器在实际生成最终编译的二进制文件之前会生成大量代码。在这种情况下，

行0

是编译器告诉您它在编译

TableViewController.swift

时生成代码的方式，但该代码与原始源代码中的特定行不对应

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

我对苹果以这种方式传达这一事件感到失望，但我们无能为力。我的理解是侏儒可以描述这种事情。但是，要么苹果没有使用这个工具，要么它没有写入崩溃报告，要么很可能两者都没有

您可以使用

atos

或

dwarfdump

对地址进行符号化

0x0000000102c92748

来验证此行为。我打赌它会输出完全相同的东西-第0行。在过去，我曾使用

dwarfdump

在这里查看是否有更多信息编码在dSYM中，但我没有找到任何东西。不过那是几年前的事了，所以事情可能已经改变了

第三方撞车记者能帮上忙吗？

它们都使用dSYM来表示符号，因此它们所包含的信息不能超过该文件中包含的信息。不管怎样，这可能值得一试，但我怀疑你在0号线这件事上会有任何进展

但是，它们可能能够对

libswiftCore.dylib

中的帧进行符号化，这可能非常有用

为什么会发生这种崩溃？

这是一个百万美元的问题

我想看看实际的车祸细节。我猜这是一条非法指令，因为您在swift运行库中崩溃了。可能发生的情况是，运行时遇到了某种非法状态。打开一个nil

可选的

包肯定就是它。也可能是越界

范围

操作。我认为越界数组索引也可能以这种方式失败，但我不确定

我要做的就是仔细看看

TableViewController.sendSmsMessage（sender:）

中发生了什么。请密切注意上面列出的内容，特别是当它与任何通用标准库函数交互时

我还尝试将那些

libswiftCore.dylib

帧符号化。同样，您可以使用

atos

，只需将其指向库本身并使用加载地址即可。我不确定Xcode在内部将Swift库保存在哪里，因此您可能只使用与应用程序捆绑在一起的库的副本

祝你好运

那么，你的应用程序通过TestFlight安装后，会在真实设备上崩溃吗？当您通过XCode构建和安装它时，您不能在XCode模拟器上复制它吗？只是想澄清一下，看看。第0行很可能意味着编译器已经为您生成了代码，并且与源代码中的实际行不对应。由于那里的

专业化

，我倾向于认为这里就是这种情况。在偏移量

0x102c92748

上设置一个断点，然后逐步执行…我不认为，您可以将

调试

发送给TF。我几乎100%确信，正如你所说，TF会迫使释放。您可以在一个真正的设备上构建它，将其设置为UK语言环境，并在连接到XCode和

所有异常时尝试使其崩溃。@Václav，这是个好主意。让我试试。谢谢@Mattie！我尝试了一些经常被建议的东西，比如你描述的——符号化，atos
，等等。我仍然得到同样的东西：第0行。一个新的发展是，我能够让用户向我发送一份崩溃报告，但它似乎同样没有用。我完全同意，做一些调查工作来隔离问题可能比依赖崩溃报告更容易。一个问题是，crash reporter似乎给我的唯一信息是发生崩溃的函数，但这是一个巨大的函数。我开始认为，实现这一点的唯一方法是将其分解为许多较小的函数，以提供更具体的指示，说明崩溃是在哪里触发的。我知道获得行号是很好的，但您无法做到这一点。编译器没有在任何地方对该信息进行编码-它已消失：（你有没有试着象征那些libswiftCore.dylib框架？另一方面，这些可以给你一个线索。至于重构那个函数，一定要去尝试！我会尝试一下。我会接受你的答案，因为它解释了这里发生的事情。谢谢你的帮助！很高兴能提供帮助！