EXC_BREAKPOINT崩溃的原因范围 [英] Scope of causes for EXC_BREAKPOINT crash
问题描述
我在Fabric中具有以下堆栈跟踪：
I have this stack trace in Fabric:
我的问题：从崩溃日志中，函数'formatMessageAuthorName'是造成此EXC_BREAKPOINT崩溃的唯一原因吗？例如，除了此函数中的代码外，还有其他可能导致崩溃的原因吗？
My question: From the crash log, is the function 'formatMessageAuthorName' the only cause for this EXC_BREAKPOINT crash? E.g., are there other possible causes for the crash apart from the code inside this function?
这是我的formatMessageAuthorName函数：
Here is my formatMessageAuthorName function:
private static func formatMessageAuthorName(firstname: String, lastname: String?=nil) -> String {
// Capitalise first character of firstname
var Cap_firstname = firstname
Cap_firstname.replaceRange(Cap_firstname.startIndex...Cap_firstname.startIndex, with: String(Cap_firstname[Cap_firstname.startIndex]).capitalizedString)
guard let lastname = lastname else { return Cap_firstname }
// if has lastname & first char, capitalise too and concat with firstname.
if let firstCharLastName = lastname.characters.first {
return "\(Cap_firstname) \(String(firstCharLastName).uppercaseString)."
} else {
return firstname
}
}
我的假设
我知道会使函数崩溃的唯一线索是，当 firstname为空字符串时，它将由于它访问无效的数组索引而在此处崩溃：
The only clue that I know that will make the function crash is when 'firstname' is an empty string, it will crash here since it accesses invalid array index:
String(Cap_firstname[Cap_firstname.startIndex])
但是，我仍然对此假设持怀疑态度，因为我非常确定'firstname'不为空（它是从服务器检索到的） ）。我什至通过登录具有此崩溃的某些用户帐户并使用该页面（MessageViewController），进行了测试，但是我自己从未崩溃，并且正确显示了名字。由于我从iOS 8、9和10崩溃时似乎也与iOS版本无关。
However, I'm still skeptical about this assumption, since I'm quite sure that 'firstname' is not empty (it's retrieved from server). I even tested it by logging into some user accounts that has this crash, and using that page (MessageViewController), but I never had the crash myself and firstname is shown correctly. It also seems to not be about iOS versions as I received crash from iOS 8, 9, and 10.
在最近一次崩溃之后，我经常遇到此崩溃（> 300）应用程序更新，我不知道为什么以前从未发生过，这里的代码不会在更新中更改，而且我也永远无法与受影响的用户一起复制它。
I have this crash a lot (>300) after my recent app update and I have no idea why as it never happens before, the code here does not change through the update, and I can never reproduce it with the effected users.
如果罪魁祸首只能是此函数中的代码，而没有其他可能性（例如多线程，Realm等），那么我可以转向关注服务器问题，例如 firstname可能是一个空字符串。但是，我仍然无法想象它会如何发生，因为我已经使用了这些用户帐户，而且自己从来没有崩溃过。
If the culprit can only be the code in this function, and no other possibilities (like multi-threading, Realm etc.), I can turn to focus on the server issues instead, like how 'firstname' might be an empty string. But still, I can't imagine how it could happen, since I already used those user accounts and never have this crash myself.
非常感谢。
推荐答案
EXC_BREAKPOINT总是通过执行某种陷阱指令（*）来触发，并且异常直接传递到执行陷阱指令的线程上。因此，如果您看到崩溃报告说该堆栈中的该线程获得了EXC_BREAKPOINT，则意味着该线程确实对执行陷阱指令的操作有用。
EXC_BREAKPOINT is always triggered by executing a trap instruction of some sort(*) and the exception gets delivered directly to the thread that executed the trap instruction. So if you are seeing a crash report that says this thread with this stack got an EXC_BREAKPOINT, that means that thread really did to something that executed a trap instruction.
您可以可能是通过查看二进制文件中的崩溃地址看到的，您将在其中看到某种陷阱指令。迅速的标准库使用陷阱指令来发出各种无效的访问错误信号，并且该代码很可能内联到崩溃的函数中。因此，这可以理解上面的示例。
You could probably see this by looking at the crash address in your binary, you will see some kind of trap instruction there. The swift standard library uses trap instructions to signal various kinds of invalid access errors, and that code probably got inlined into the function that's crashing. So this makes sense of your example above.
（*）EXC_BREAKPOINT也可以用于数据监视，但这不是这里发生的事情，无论如何它们仍然可以交付到访问监视数据的线程...
(*) EXC_BREAKPOINT can also be used for data watches, but that's not what's happening here, and anyway they would still be delivered to the thread that accessed the watched data...
这篇关于EXC_BREAKPOINT崩溃的原因范围的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
