App crash on iOS 13 with dyld3::closure::ObjCStringTable::hash(char const*, unsigned long)

Incident Identifier: 7A9281BF-EB63-47CF-BEE8-460E68CC2B45

CrashReporter Key: 06be47b1c91afef9b50c551c295c757b6b152510

Hardware Model: iPhone9,1

Process: *** [1822]

Path: /private/var/containers/Bundle/Application/47D8070F-B20F-4ADC-9E8D-8F43997B480C/***.app/***

Identifier: com.***.***

Version: 633 (5.2.0)

AppStoreTools: 11A1002b

AppVariant: 1:iPhone9,1:13

Code Type: ARM-64 (Native)

Role: unknown

Parent Process: launchd [1]

Coalition: com.***.*** [1934]

Date/Time: 2019-09-15 07:16:48.9724 +0800

Launch Time: 2019-09-15 07:15:14.7595 +0800

OS Version: iPhone OS 13.1 (17A5837a)

Release Type: Beta

Baseband Version: 7.00.01

Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGBUS)

Exception Subtype: KERN_MEMORY_ERROR at 0x00000001028bb3b4

VM Region Info: 0x1028bb3b4 is in 0x102878000-0x1028bc000; bytes after start: 275380 bytes before end: 3147

REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL

__LINKEDIT 0000000102734000-0000000102878000 [ 1296K] r--/r-- SM=COW

---> mapped file 0000000102878000-00000001028bc000 [ 272K] r--/rw- SM=COW ...t_id=3eb67cef

Kernel Alloc Once 00000001028bc000-00000001028c4000 [ 32K] rw-/rwx SM=PRV

Termination Signal: Bus error: 10

Termination Reason: Namespace SIGNAL, Code 0xa

Terminating Process: exc handler [1822]

Triggered by Thread: 14

Thread 14 name:

Thread 14 Crashed:

0 libdyld.dylib 0x00000001a38356c0 dyld3::closure::ObjCStringTable::hash(char const*, unsigned long) const + 16 (Closure.cpp:1339)

1 libdyld.dylib 0x00000001a3835cd4 dyld3::closure::ObjCStringTable::getIndex(char const*) const + 52 (Closure.h:840)

2 libdyld.dylib 0x00000001a3835b54 dyld3::closure::ObjCClassOpt::forEachClass(char const*, dyld3::Array<std::__1::pair<unsigned long... + 52 (Closure.cpp:1397)

3 libdyld.dylib 0x00000001a38424f8 dyld3::AllImages::forEachObjCClass(char const*, void (void*, bool, bool*) block_pointer) const + 132 (AllImages.cpp:1922)

4 libobjc.A.dylib 0x00000001a3774c38 getPreoptimizedClass + 148 (objc-opt.mm:279)

5 libobjc.A.dylib 0x00000001a375f8d8 getClassExceptSomeSwift(char const*) + 20 (objc-runtime-new.mm:1607)

6 libobjc.A.dylib 0x00000001a3760784 look_up_class + 100 (objc-runtime-new.mm:6843)

7 Foundation 0x00000001a3df2b00 NSClassFromString + 200 (NSObjCRuntime.m:0)

8 Foundation 0x00000001a3de3264 _decodeObjectBinary + 1708 (NSKeyedArchiver.m:2472)

9 Foundation 0x00000001a3de2928 _decodeObject + 340 (NSKeyedArchiver.m:3013)

10 Foundation 0x00000001a3cf2050 -[NSKeyedUnarchiver decodeObjectForKey:] + 168 (NSKeyedArchiver.m:3035)

11 Foundation 0x00000001a3cf1eac -[NSKeyedUnarchiver decodeObjectOfClasses:forKey:] + 352 (NSKeyedArchiver.m:3069)

12 Foundation 0x00000001a3cf1b04 -[NSCoder(Exceptions) __tryDecodeObjectForKey:error:decodeBlock:] + 96 (NSCoder.m:557)

13 Foundation 0x00000001a3cf1a7c -[NSCoder decodeTopLevelObjectOfClasses:forKey:error:] + 108 (NSCoder.m:360)

14 LocationSupport 0x00000001aad4b170 CLConnectionMessage::getObjectOfClasses(NSSet*) const + 176 (CLConnection.mm:690)

15 CoreLocation 0x00000001a6b4890c invocation function for block in _CLClientCreateConnection(__CLClient*) + 224 (CLClient.mm:1155)

16 LocationSupport 0x00000001aad4ff64 invocation function for block in CLConnectionClient::setDefaultMessageHandler(void (std::__1::sha... + 68 (CLConnectionClient.mm:379)

17 LocationSupport 0x00000001aad4fe90 invocation function for block in CLConnectionClient::setDefaultMessageHandler(void (std::__1::sha... + 140 (CLCallbackDropManager.h:46)

18 LocationSupport 0x00000001aad496ec CLConnection::handleMessage(std::__1::shared_ptr<CLConnectionMessage>) + 180 (CLConnection.mm:232)

19 LocationSupport 0x00000001aad495a4 invocation function for block in CLConnection::initializeConnection_nl() + 60 (CLConnection.mm:210)

20 LocationSupport 0x00000001aad4b828 invocation function for block in setEventHandler(NSObject<OS_xpc_object>*, void (std::__1::shared... + 484 (CLConnection.mm:348)

21 libxpc.dylib 0x00000001a35fe54c _xpc_connection_call_event_handler + 68 (connection.c:0)

22 libxpc.dylib 0x00000001a35fe8c4 _xpc_connection_mach_event + 876 (connection.c:1208)

23 libdispatch.dylib 0x00000001a36fe244 _dispatch_client_callout4 + 16 (object.m:535)

We're seeing an identical stack trace on iOS 13 devices only.

Are you utilizing the Firebase SDK by any chance? I believe that's where the issue lies.

Can confirm identical crash reports for iOS 13 devices, only.

Filed an Apple bug report #: FB7296430.

Hey, adamup928, just in case, we're observing the similar issue and yes, we're using Firebase SDK

Just in case, we're observing similar crashes, involving CLConnectionClient, however we also see some crashes not involving CLConnectionClient:

Crashed: com.apple.runningboardservices.connection.incoming
0  libdyld.dylib                  0x18c828684 dyld3::closure::ObjCStringTable::hash(char const*, unsigned long) const + 16
1  libdyld.dylib                  0x18c828c98 dyld3::closure::ObjCStringTable::getIndex(char const*) const + 52
2  libdyld.dylib                  0x18c828b18 dyld3::closure::ObjCClassOpt::forEachClass(char const*, dyld3::Array<std::__1::pair<unsigned long, unsigned long> > const&, void (void*, bool, bool*) block_pointer) const + 52
3  libdyld.dylib                  0x18c8354c4 dyld3::AllImages::forEachObjCClass(char const*, void (void*, bool, bool*) block_pointer) const + 132
4  libobjc.A.dylib                0x18c767c38 getPreoptimizedClass + 148
5  libobjc.A.dylib                0x18c7528d8 getClassExceptSomeSwift(char const*) + 20
6  libobjc.A.dylib                0x18c753784 look_up_class + 100
7  Foundation                     0x18cde52ec NSClassFromString + 200
8  BaseBoard                      0x18f5c0b2c _BSXPCDecodeObject + 2000
9  BaseBoard                      0x18f5be49c _BSXPCDecodeObjectForKey + 288
10 RunningBoardServices           0x18f55976c -[RBSXPCMessage decodeArgumentCollection:withClass:atIndex:allowNil:error:] + 416
11 RunningBoardServices           0x18f545da8 __32-[RBSConnection _handleMessage:]_block_invoke_2.337 + 92
12 libsystem_trace.dylib          0x18c5d3708 _os_activity_initiate_impl + 56
13 RunningBoardServices           0x18f5459d0 -[RBSConnection _handleMessage:] + 784
14 RunningBoardServices           0x18f5464fc __30-[RBSConnection _lock_connect]_block_invoke + 88
15 libxpc.dylib                   0x18c5f258c _xpc_connection_call_event_handler + 68
16 libxpc.dylib                   0x18c5f2904 _xpc_connection_mach_event + 876
17 libdispatch.dylib              0x18c6f128c _dispatch_client_callout4 + 16
18 libdispatch.dylib              0x18c6adc64 _dispatch_mach_msg_invoke$VARIANT$mp + 380
19 libdispatch.dylib              0x18c69d3f0 _dispatch_lane_serial_drain$VARIANT$mp + 300
20 libdispatch.dylib              0x18c6ae864 _dispatch_mach_invoke$VARIANT$mp + 472
21 libdispatch.dylib              0x18c69d3f0 _dispatch_lane_serial_drain$VARIANT$mp + 300
22 libdispatch.dylib              0x18c69df48 _dispatch_lane_invoke$VARIANT$mp + 468
23 libdispatch.dylib              0x18c6a7400 _dispatch_workloop_worker_thread + 588
24 libsystem_pthread.dylib        0x18c740fa8 _pthread_wqthread + 276
25 libsystem_pthread.dylib        0x18c743ae4 start_wqthread + 8

In our case it looks like it's an issue with lack of background fetch capability that results in watchdog killing the app. We're able to reproduce it with the steps in https://github.com/firebase/firebase-ios-sdk/issues/3759

We are seeing both of those exact same crashes on iOS 13. We are not using Firebase.

Are you using NSFileProtectionComplete in your entitlements? We found a *strong* correlation between using NSFileProtectionComplete and the crash, which would happen soon after device lock.

We were able to temporarily work around this issue by switching to NSFileProtectionCompleteUntilFirstUserAuthentication, then locking specific directories with NSFileProtectionComplete.

Hello, we are seeing similar crashes like this as well. Did you find any conclusive evidence or more information about the NSFileProtectionComplete and the crash? Thanks 🙂

It seems that the dyld3 saves the generated clojure files in the app tmp directory and if you use NSFileProtectionComplete the clojure files have this property too. To generate a crahs close the app, lock the phone, send a push that will wake up the app and then the crash is generated.

The solution seems to be simple, just change the permissions for the app tmp direcptry to NSFileProtectionCompleteUntilFirstUserAuthentication and the app will not crash.

I really don't know why apple did this.

We have the same issue but it does not seem to be solved by the fix recommended by Alex T. Has anybody else tried this?

This is completely baffling. Currently running ios 13.1.2, and the primary issue is only seen on XR. I can force a crash by turning the phone to horizontal orientation right as I lock it (which causes a split screen in our app on larger phones like XR).

We have noticed that when we do not allow Location (While in use), we do not get the first exception with CoreLocation. But then we get the com.apple.runningboardservices.connection.incoming or a BSXPCCNx:com.apple.frontboard.systemappservices crash. Either way, the stack trace ends in the dyld3::closure.

Looking back, this didn't start when I updated to iOS 13 beta. It didn't even start when I was using the XCode 11 beta. Somewhere around the time I switched to XCode 11 it started, but we didn't notice it at first. If I load the build prior to that from TestFlight, built with XCode 11 (GM seed I think), no crash. Also, it will not crash if built/loaded from XCode (DEBUG version), but only from TestFlight or App Store.

Since I know which build the crashes started with, I went back to an older commit and rebuilt source code from there. It still crashes.

I removed XCode 11 entirely (and the various cached files), installed XCode 10.3 and rebuilt, but it is still crashing.

I realized that I had also started a new branch right around the time it broke and added a Personal VPN entitlement in the new branch, which forced me to update my Provisioning Profile. When we noticed the crashing, I switched back to the main branch to try to fix. Completely grasping at straws by this point, just in case it mattered, I even removed the Personal VPN entitlement and deleted all old provisioning profiles. It is still crashing.

I have uninstalled/reinstalled the app several times after various attempts at fixes too just in case it helped. I may open a support ticket or repost this in a different thread, but thought I'd see if anyone here tried Alex T's suggestion or tried other things that might work?

I can't release our app like this, but I also currently changed the app wide Data Protection entitlement from NSFileProtectionComplete to NSFileProtectionCompleteUntilFirstUserAuthentication (which I think is default) just to see if that chagnes anything. Waiting for TestFlight to finish processing to test that.

Looks like changing the app wide Data Protection entitlement from NSFileProtectionComplete to NSFileProtectionCompleteUntilFirstUserAuthentication instead of just the temp directory worked (though more testing is needed). But that creates other issues for us. Anyone know if this is on Apple's radar?

Feedback filed. The ticket number is FB7347161.

I've figured out a set of steps that causes the crash every time when the Data Protection entitlement is enabled. As soon as data protection is turned off, a crash does not occur.

These steps will cause a crash even on an unmodified Xcode application template (single-view application, for example):

Steps to reproduce:

1. Run application without debugger attached (to enable watchdog timers)
2. Lock device (while the application is in the foreground)
3. Wait 15 seconds
4. Rotate device to landscape while locked (give it a good shake so you know the new orientation has been recognized)
5. Wake and unlock device
6. App has crashed

I'm seeing similar crash reports appearing in organizer. It is not something I am able to reproduce, the suggestions here don't cause it for me. Only one instance has been an Xr. Others have been XS Max, 6s+, 7, 8+ so is something that could happen on any device.

I do have NSFileProtectionComplete set as the app default like others, just no way of seeing if that fixes the problem short of pushing an update with it changed.