ios - Crashlytics iOS - 在第 0 行崩溃 - Swift 来源

Question

当发生崩溃时，我目前正面临一些 Swift 源文件的问题。事实上，在 Crashlytics 上，我有一个关于线路和崩溃原因的奇怪信息。它告诉我源代码已在 第 0 行 崩溃，并给我一个 SIGTRAP 错误。我读到当线程遇到断点时会发生此错误。但问题是这个错误是在我没有调试时发生的(来自 TestFlight 的应用程序测试)。

这是一个示例，当 Crashlytics 告诉我第 0 行有一个SIGTRAP 错误时:

// Method that crashs  
private func extractSubDataFrom(writeBuffer: inout Data, chunkSize: Int) -> Data? {  

        guard chunkSize > 0 else { // Prevent from having a 0 division  
            return nil  
        }  

        // Get nb of chunks to write (then the number of bytes from it)  
        let nbOfChunksToWrite: Int = Int(floor(Double(writeBuffer.count) / Double(chunkSize)))  
        let dataCountToWrite = max(0, nbOfChunksToWrite * chunkSize)  
        guard dataCountToWrite > 0 else {  
            return nil // Not enough data to write for now  
        }  

        // Extract data  
        let subData = writeBuffer.extractSubDataWith(range: 0..<dataCountToWrite)  
        return subData    
}  

另一个 Swift 文件，用于解释“writeBuffer.extractSubDataWith(range: 0..

public extension Data {  

    //MARK: - Public  
    public mutating func extractSubDataWith(range: Range) -> Data? {  

        guard range.lowerBound >= 0 && range.upperBound <= self.count else {  
            return nil  
        }  

        // Get a copy of data and remove them from self  
        let subData = self.subdata(in: range)  
        self.removeSubrange(range)  

        return subData  
    }  
}  

你能告诉我我做错了什么吗？或者这个奇怪的 SIGTRAP 错误会发生什么？

谢谢

Answer 1

一行零崩溃确实很奇怪。但是，在 Swift 代码中很常见。

Swift 编译器可以为您生成代码。对于泛型函数，这种情况经常发生，但也可能由于其他原因而发生。当编译器生成代码时，它还会为它生成的代码生成调试信息。此调试信息通常引用导致代码生成的文件。但是，编译器用一行 0 标记了这一切以区别于开发人员实际编写的代码。

这些通用函数也不必由您编写 - 我已经看到标准库函数也发生过这种情况。

(旁白:我相信 DWARF 标准实际上可以更准确地描述这种情况。但不幸的是，Apple 似乎并没有那样使用它。)

Apple 通过我多年前提交的 Radar 验证了此零线行为。如果您想确认，您还可以查看应用程序自己的调试数据(例如通过 dwarfdump)。

您可能想要尝试这样做的一个原因是，如果您真的不相信 Crashlytics 正确地标记了线条。他们的用户界面和原始崩溃数据之间有很多东西。可以想象出了什么问题。您可以确认这一点的唯一方法是获取崩溃地址 + 二进制文件，然后自己进行查找。如果 dwarfdump 告诉您这发生在第 0 行，则证实这只是编译时代码生成的产物。

不过，我倾向于认为 Crashlytics 用户界面没有任何问题。我只是想指出它的可能性。

至于 SIGTRAP - 一点也不奇怪。这只是表明正在运行的代码已决定终止进程。例如，这不同于 SIGBUS，在 SIGBUS 中操作系统执行终止。这可能是由 Swift 整数和/或范围边界检查引起的。您的代码确实在这两个地方都有一些类似的东西。而且，由于这对性能至关重要 - 将成为内联代码生成的主要候选对象。

更新

现在看来，至少在某些情况下，编译器现在也使用 <compiler-generated> 的文件名。 .我相信他们这样做是为了让这个案子更清楚。所以，可能是使用更新版本的 Swift，你会看到 <compiler-generated>:0 .这可能无助于追踪崩溃，但至少会使事情变得更加明显。