Unknown Insta-Crash With NO_CRASH_STACK

Hi!

We've recently released an usual app-update, but suddenly got a bunch of crashes in App Store Connect and almost none in Firebase Crashlytics.

According to customer support, for some users the app insta-crashes. A white screen appears for a flash and then they're returned to the home screen. The app always insta-crashes, only a reinstall fixes it.

It makes sense while Crashlytics isn't reporting any crashes, because it doesn't even get a chance to run and upload the crash reports to their server.

The Xcode organizer does show a bunch of crashes, but with no stack trace. It just says MyApp: NO_CRASH_STACK. Looking at the explicit 'xccrashpoint' in Finder reveals a couple of crash reports, that I've attached, but they're not that useful.

As far as I can tell, the app crashes while it's trying to load the Swift core, that's embedded in the app, but I'm not sure why that would cause a crash. Maybe it was supposed to use the library embedded in iOS (/usr/lib/swift/libswiftCore.dylib)?

Any help would be greatly appreciated 🍺!

Replies

We've managed to solve the issue.

The root cause was that it was trying to run the embedded Swift libraries (that are meant for iOS < 13) on iOS 13+.

  1. The app was crashing randomly, but reinstalls always seemed to fix it.

According to an Apple engineer, this is because during app thining the App Store will strip out the embedded Swift runtime library for iOS 13+.

Why it didn't do this in some cases & caused random crashes, I do not know.

  1. otool -L shows that the new version no longer had @rpath&#x2F;libswiftos.dylib marked as weak. Maybe this confused the app thinning process for some users and caused it to not strip the embedded Swift libraries? Not sure how out of the 22 embedded libswift% libraries only this one wasn't marked as weak. There's no clear Xcode setting for this that we might have accidetanlly flipped.

We did add a new 3rd party dependency via SPM in the new version, so maybe that changed something somewhere.

  1. otool -l shows the right order in tries to load the libraries (see cmd LC_RPATH). The order matches the LD_RUNPATH_SEARCH_PATHS setting in Xcode. &#x2F;usr&#x2F;lib&#x2F;swift was the first in there, before @executable_path&#x2F;Frameworks, so not sure why the crash ever happened, even if the libraries were embedded. Guessing because of the lib from 2 not being marked as weak.

To fix it, we just removed support for iOS 11 & 12. If there are no embedded Swift libraries, there's nothing to link to & crash on iOS 13+.

Further update, we found the root problem!

It was because the 3rd party dependency had the load commands in the wrong order (otool -l):

          cmd LC_LOAD_WEAK_DYLIB
      cmdsize 48
         name @rpath&#x2F;libswiftos.dylib (offset 24)
   time stamp 2 Thu Jan  1 02:00:02 1970
      current version 1023.0.0
compatibility version 1.0.0
Load command 46
          cmd LC_RPATH
      cmdsize 40
         path @executable_path&#x2F;Frameworks (offset 12)
Load command 47
          cmd LC_RPATH
      cmdsize 40
         path @loader_path&#x2F;Frameworks (offset 12)
Load command 48
          cmd LC_RPATH
      cmdsize 32
         path &#x2F;usr&#x2F;lib&#x2F;swift&#x2F; (offset 12)

So besides checking at the load commands for the main binary, we also had to check each individual dependency/dynamic framework.

@adiracu please guide me in the correct order