CommonCrypto swift module error in App

I think you’ve misunderstood what’s actually failing here. CommonCrypto is present and functional on all builds of macOS for which you can build Swift code. I’m not sure why things are crashing on that other Mac, but it’s very unlikely to be caused by CommonCrypto per se.

Let’s start with the basics. Please grab the crash report off the affected machine and post it here. See Posting a Crash Report for advice on how to do that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks Quinn,

Seeking to discard any other cause, I isolate the code that uses CommonCrypto in a separated app and run it. Same behavior. In my computer run perfectly well, but when trying to use the very same app in another Mac (in this case a MacBook air M2) it crashes immediately with the message "...quit unexpectedly" (Attached the crash log it offered just after the failure).

So, I'm pretty sure this is somehow caused by CommonCrypto. I even tried using the package CryptoSwift but fails exactly the same way.

Any help will be highly appreciated.

Thanks

Thanks for the crash report.

Consider this:

Code Type:             X86-64 (Translated)

…

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)

On Intel, these SIGILL crashes are usually the result of a trap, that is, the program has detected a failure and crash itself deliberately. See here. And that’s exactly what’s going on here. Consider the crashing thread backtrace:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libswiftCore.dylib … closure #1 in closure #1 in closure #1 in _assertionFailure(_:_:file:line:flags:) + 315
1   libswiftCore.dylib … closure #1 in closure #1 in _assertionFailure(_:_:file:line:flags:) + 366
2   libswiftCore.dylib … closure #1 in _assertionFailure(_:_:file:line:flags:) + 123
3   libswiftCore.dylib … _assertionFailure(_:_:file:line:flags:) + 230
4   libswiftCore.dylib … Array._checkSubscript(_:wasNativeTypeChecked:) + 129
5   libswiftCore.dylib … Array.subscript.getter + 78
6   TestLicense        … closure #1 in closure #1 in testLicenseView.body.getter + 970
7   SwiftUI            … 0x7ff91d9dc000 + 18271647

Frame 7 is SwiftUI calling your code in frame 6. That code is indexing into an array (frame 5) which has trapped, almost certainly because the index is out of bounds (frame 4). Frames 3 through 0 are all standard stuff you’ll see in such a trap.

I’m not sure why removing CommonCrypto prevents this crash, but the crash itself has nothing to do with that framework. I recommend that you look at the implementation of testLicenseView to see why it’s trapping.

Note that the crash report doesn’t include a source file and a line number. For info on how to get that — a process known as symbolication — see Adding identifiable symbol names to a crash report. However, even if you can’t symbolicate it’s likely that the unsymbolicated log contains enough info to debug this.

Finally, some notes:

• You’re running an Intel build on Apple silicon, which relies on Rosetta. I recommend that you build your app natively. If history repeats itself, Rosetta won’t be around forever.

• In the Swift API Design Guidelines, type names begin with a capital letter. So testLicenseView should be TestLicenseView. This isn’t required by the language, but if you don’t follow the guidelines you’ll confuse anyone else reading your code.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for the extremely enlightening comment. I very much appreciate it!

Please, when possible, comment on the following:

"I’m not sure why removing CommonCrypto prevents this crash..." As I mentioned, this is a large application that uses CommonCryto at the very beginning. As just by bypassing the code where it was being used, the app worked fine, AND the app was working fine also on the Intel MacBook (with the very same code), my conclusion (now proved erroneous) was to indict ARM - "CommonCrypt" as the culprit.

With your feedback, I reviewed the code and I think the error should had occurred on these instructions (particularly on the readLicense() one):
// if licenseFileFound { // let licenseDetails = readLicense().components(separatedBy: "\n") // self.licenseType = licenseDetails[0] // self.licenseSerial = licenseDetails[1] // else { // self.licenseStatus = "File not found" // }

Where readLicense function returns a string after processing an encrypted file using CommonCrypto. For some reason that I ignore, it recognizes the text stream from the read file correctly when working within Intel - T2 environment, but fails when the app was ported to ARM. Can you give me some hints on how to look so to dig into this error and understand why it works fine on an Intel hardware and fails on ARM hardware (the very same code)?

It looks like you’re using Swift. CommonCrypto is a C API and thus full of unsafe pointers. In my experience, most mysterious “CommonCrypto works here but fails there” problems are related to undefined behaviour. It’s easy to write CommonCrypto code that relies on undefined behaviour, and then that code may work or fail depending on the various factors, including the OS version, the hardware, other stuff going on it your process at that time, and so on.

You should review your CommonCrypto code for such problems. To get you started, here’s an example of how to correctly use it from Swift to implement AES-CBC with PKCS#7 padding.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"