Crashlytics iOS - 第 0 行崩溃 - Swift 来源 [英] Crashlytics iOS - Crash at line 0 - Swift sources

问题描述

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

I'm currently facing a problem with some Swift source files when a crash occurs. Indeed, on Crashlytics I have a weird info about the line and the reason of the crash. It tells me the source has crashed at the line 0 and it gives me a SIGTRAP error. I read that this error occurs when a Thread hits a BreakPoint. But the problem is that this error occurs while I'm not debugging (application test from TestFlight).

以下是 Crashlytics 告诉我第 0 行存在 SIGTRAP 错误的示例:

Here is an example when Crashlytics tells me there's a SIGTRAP Error at line 0 :

// 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..

Another Swift file to explain what happens at the line "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 错误会发生什么?

Could you tell me what I'm doing wrong ? Or what can occurs this weird SIGTRAP error ?

谢谢

推荐答案

零线崩溃确实很奇怪.但是，在 Swift 代码中很常见.

Crashing with a line of zero is indeed weird. But, common in Swift code.

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

The Swift compiler can do code generation on your behalf. This can happen quite a bit with generic functions, but may also happen for other reasons. When the compiler generates code, it also produces debug information for the code it generates. This debug information typically references the file that caused the code to be generated. But, the compiler tags it all with a line of 0 to distinguish it from code that was actually written by the developer.

这些通用函数也不必由您编写 - 我也见过标准库函数也会发生这种情况.

These generic functions also do not have to be written by you - I've seen this happen with standard library functions too.

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

(Aside: I believe that the DWARF standard can, in fact, describe this situation more precisely. But, unfortunately Apple doesn't seem to use it in that way.)

Apple 通过我几年前提交的雷达验证了这条零线行为.如果您想确认，也可以查看应用程序自己的调试数据(例如通过 dwarfdump).

Apple verified this line zero behavior via a Radar I filed about it a number of years ago. You can also poke around in your app's own debug data (via, for example dwarfdump) if you want to confirm.

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

One reason you might want to try to do this, is if you really don't trust that Crashlytics is labelling the lines correctly. There's a lot of stuff between their UI and the raw crash data. It is conceivable something's gone wrong. The only way you can confirm this is to grab the crashing address + binary, and do the lookup yourself. If dwarfdump tells you this happened at line zero, then that confirms this is just an artifact of compile-time code generation.

但是，我倾向于相信 Crashlytics 用户界面没有任何问题.我只是想指出它是一种可能性.

However, I would tend to believe there's nothing wrong with the Crashlytics UI. I just wanted to point it out as a possibility.

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

As for SIGTRAP - there's nothing weird about that at all. This is just an indication that the code being run has decided to terminate the process. This is different, for example, from a SIGBUS, where the OS does the terminating. This could be caused by Swift integer and/or range bounds checking. Your code does have some of that kind of thing in both places. And, since that would be so performance-critical - would be a prime candidate for inline code generation.

更新

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

It now seems like, at least in some situations, the compiler also now uses a file name of <compiler-generated>. I'm sure they did this to make this case clearer. So, it could be that with more recent versions of Swift, you'll instead see <compiler-generated>:0. This might not help tracking down a crash, but will least make things more obvious.

这篇关于Crashlytics iOS - 第 0 行崩溃 - Swift 来源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！