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

问题描述

当发生崩溃时，我目前正遇到一些Swift源文件的问题。确实，在Crashlytics上，我有关于该行和崩溃原因的奇怪信息。它告诉我源已在第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告诉我有一个 SIGTRAP时第0行错误：

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（范围：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正确标记了行。用户界面和原始崩溃数据之间有很多联系。可以想象出现了问题。您可以确认的唯一方法是获取崩溃的地址+二进制文件，然后自己执行查找。如果dwarfdump告诉您这是在零行发生的，则可以确认这只是编译时代码生成的产物。

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 UI。我只是想指出一种可能性。

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：$$$ c>。这可能无助于跟踪崩溃，但至少会使事情变得更明显。

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屋！