Recently, I have upgraded my Xcode version from 9.2 to 11.3.1. My project, which was written in Swift 4, worked completely fine in 9.2. However, when trying to run it in 11.3.1, I have been experiencing random "EXC_BAD_ACCESS" crashes in areas of code that previously worked just fine. Now, the areas of code that are being affected are essentially identical to previous sections of the code, and when stepping through the code, every condition appears to be working just fine (nothing is nil or anything like that). I enabled zombie objects to check for deallocation, but I found nothing. Is there any particular issue with regards to upgrading to Xcode 11 I should be aware of, and any ideas of what might be causing this?
Xcode 11 upgrade resulting in random crashes
It’s not uncommon to see problems like this after a compiler upgrade. In most case these are not actually bugs in the compiler, but rather the result of your code relying on undefined behaviour that just happened to work out favourably in the previous compiler. This is less common in Swift than, say, Objective-C but it’s still possible [1].
You’ve already tried zombies, which is the first thing I’d suggest here (-: The next step is ASan. See my Standard Memory Debugging Tools post for info on how to set that up.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] For example, code like this:
var s = [UInt8]("Hello Cruel World!".utf8)
let p = UnsafeRawPointer(&s).assumingMemoryBound(to: CChar.self)
let l = strlen(p)
Here the developer is trying to call a C API that wants a pointer to CChar, that is, SInt8, but the contents of their array is made up UInt8. The problem is that the pointer generated by the & on line 2 is only guaranteed to be valid for the duration of the UnsafeRawPointer.init(_:) call. Thus, it’s dangling by the time they call strlen on line 3.
The Swift compiler in Xcode 11.4 does it’s best to warn you about this specific problem, but it can’t catch all of them and, anyway, this is just one of many ways you can go wrong with ‘unsafe’ APIs.