Scope of causes for EXC_BREAKPOINT crash

问题

I have this stack trace in Fabric:

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?

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
    }
}

My assumption

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])

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.

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.

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.

Thanks a lot.

回答1:

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

来源：https://stackoverflow.com/questions/42434741/scope-of-causes-for-exc-breakpoint-crash