Crash when requesting location authorisation on app startup

I'm trying to diagnose a crash we're seeing in an app that's on TestFlight at the moment.

We have the background location permission and are woken by various events, e.g. the significant location change event. I believe the app is being woken in the background and within a few seconds (about 7s in the example below) the app crashes. The crash appears to be when we are confirming what location authorisation the app currently has.

As far as we know this is only happening for a single user.

Any thoughts on what could be happening? Other forum posts led me to believe it was related to leaking background tasks but I didn't think that was likely after only 7s (and there's no actual mention of background tasks in the crash).

Other threads in the crash log have core data relate tasks going on and while we've done a lot of work on our multi-threaded core data I could imagine that being a cause, but surely that would show as a crash on the threads involved rather than thread 0?

Any help appreciated, crash log below.

John


AppVariant:          1:iPhone9,3:15
Beta:                YES
Code Type:           ARM-64 (Native)
Role:                Non UI
Parent Process:      launchd [1]

Date/Time:           2021-12-13 10:31:18.0065 +0000
Launch Time:         2021-12-13 10:31:11.4169 +0000
OS Version:          iPhone OS 15.1 (19B74)
Release Type:        User
Baseband Version:    6.00.00
Report Version:      104
Exception Type:  EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Triggered by Thread:  0


Thread 0 name:
Thread 0 Crashed:
0   libsystem_kernel.dylib        	0x00000001bdd7cb10 mach_msg_trap + 8
1   libsystem_kernel.dylib        	0x00000001bdd7d134 mach_msg + 72 (mach_msg.c:119)
2   libdispatch.dylib             	0x0000000183f9c734 _dispatch_mach_send_and_wait_for_reply + 504 (mach.c:815)
3   libdispatch.dylib             	0x0000000183f9caec dispatch_mach_send_with_result_and_wait_for_reply$VARIANT$mp + 52 (mach.c:2019)
4   libxpc.dylib                  	0x00000001de30f458 xpc_connection_send_message_with_reply_sync + 236 (connection.c:974)
5   Foundation                    	0x0000000185a0387c __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__ + 12 (NSXPCConnection.m:223)
6   Foundation                    	0x0000000185a09194 -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2368 (NSXPCConnection.m:1649)
7   Foundation                    	0x0000000185a49f8c -[NSXPCConnection _sendSelector:withProxy:arg1:arg2:arg3:] + 148 (NSXPCConnection.m:1294)
8   Foundation                    	0x00000001859ece6c _NSXPCDistantObjectSimpleMessageSend3 + 80 (NSXPCDistantObject.m:282)
9   CoreLocation                  	0x000000018b0bba0c -[CLLocationInternalClient getAuthorizationStatus:forBundleID:orBundlePath:] + 140 (LocationInternal.m:786)
10  CoreLocation                  	0x000000018b0ba1fc CLInternalGetAuthorizationStatus + 268 (LocationInternal.m:2063)
11  CoreLocation                  	0x000000018b0df1c4 +[CLLocationManager _authorizationStatusForBundleIdentifier:bundle:] + 80 (CLClient.mm:1391)

Just to follow up, the app continues to work absolutely fine when the user runs it manually and it does appear to be collecting most of the data we would expect.

We are also seeing similar crashes. They are rare and hard to reliably reproduce. From what we can tell, they all involve CLLocationManager calls (including to authorizationStatus and monitoredRegions) on the main thread and when the app is backgrounded. CLLocationManager then calls into NSXPCConnection and __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__, and we're assuming that this "waiting for a synchronous reply" is slow, which then causes watchdog to kill the app. Any info or support from the Core Location team would be much appreciated.

I am also experiencing this. I submitted reports through Feedback Assistant 3 months ago but sadly I haven't had any response so far. For me I am seeing crashes from iOS 14.8+, though the number of them significantly increased from iOS 15.0 onwards. I haven't been able to find a workaround so far.

We are also experiencing similar NSXPCConnection issue, not on the authorization status request though, but when reading latest location property on CLLocationManager.

Here is the stacktrace:

0 libsystem_kernel.dylib_mach_msg_trap
1 libsystem_kernel.dylib_mach_msg
2 libdispatch.dylib__dispatch_mach_send_and_wait_for_reply
3 libdispatch.dylib_dispatch_mach_send_with_result_and_wait_for_reply$VARIANT$mp
4 libxpc.dylib_xpc_connection_send_message_with_reply_sync
5 Foundation___NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__
6 Foundation-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]
7 CoreFoundation____forwarding___
8 CoreFoundation___forwarding_prep_0___
9 CoreLocation0x1871cefe0 (0x1871cef38 + 168)
10 CoreLocation_CLClientRetrieveLocationWithDynamicAccuracyReductionAndAlteredAccessoryLocations
11 CoreLocation0x1871cc8f4 (0x1871cc5ec + 776)
12 Lyft<compiler-generated>
@nonobjc CLLocationManager.location.getter
13 LyftCoreLocationManager.swift:108:30
CoreLocationManager.location.getter
14 Lyft<compiler-generated>
protocol witness for CoreLocationManagerProtocol.location.getter in conformance CoreLocationManager
...

In our case, there is no clear pattern on app state, device or iOS version. The distribution between foreground and background app state is 3:1, i.e. in 75% reports the app is in foreground. Around 55% is iOS 15+, the rest is the earlier versions.

Any clue on possible root cause is much appreciated.

Same issue here:

Same here. It happens multiple times when our app wakes up in the background due to crossing a geofence (didEnterRegion / didExitRegion). iOS version 15.5

Any updates on this?

Same here, when asking for the CLLocationManager().authorizationStatus

Our app just got rejected by Apple review because they've experienced this crash on iPadOS 17.6.1. Still relevant.

Crash when requesting location authorisation on app startup
 
 
Q